Ability to mock classes using a 'mock()' function instead of having to define a Mock class about mockito

[BlackHC]

This is not easily possible because you cannot correct proxies with the correct type dynamically :(

[vikerman]

I am not suggesting generating the type dynamically during runtime. I am suggesting generating the code that would otherwise be written by hand using a build Transformer, since the pattern seems to be mostly the same. Would that be doable?

[matanlurey]

Is mock() with a transformer really that much of a benefit over the 2 lines you need otherwise? Plus all of your tests will now need a transformer to even work.

[vikerman]

Would it really add benefit? I guess that's the main question that needs to be answered and I don't actually know. My gut feeling was anything that would reduce developer friction while writing unit tests would be useful. I just felt it odd to repeat the same pattern over and over again and felt it could be automated.

There is also either duplication of mocked classes across test files or extra effort to collect the mocked class in a common place. Not sure how big of a problem that is either.

What sort of data would be helpful in this regard? The average number of mocked classes per unit test file? The average percentage of lines in test that goes towards writing mocks? Instances of mocked class duplications?

Regarding it being a transformer - Adding -mockito to transformers in pubspec.yaml shouldn't be difficult and we should have the default mock() implementation throw an actionable exception message saying you need to add mockito to your transformers in case it's missing. Old tests not using mock() will continue to work without the transformer.

[TedSander]

Having less code needs to be carefully balanced with having too much "magic." Magic is great when it works, but when it doesn't it is a cause of a lot of developer angst.

I don't think this savings is worth the added complexity/latency that is added to the build chain. That said if you want to setup a prototype and see how it turns out.

[Andersmholmgren]

You can of course always split out mocked classes into helper files so you
can share them between tests.

On Fri, 4 Sep 2015 at 5:08 am, Ted Sander [email protected] wrote:

Having less code needs to be carefully balanced with having too much
"magic." Magic is great when it works, but when it doesn't it is a cause of
a lot of developer angst.

I don't think this savings is worth the added complexity/latency that is
added to the build chain. That said if you want to setup a prototype and
see how it turns out.

—
Reply to this email directly or view it on GitHub
https://github.com/fibulwinter/dart-mockito/issues/20#issuecomment-137544441
.

[BlackHC]

I think the proxy issue needs to be solved in general. We're half way
there, and that's always an unfortunate location to be in ^^
On Thu 3 Sep 2015 at 22:27 Andersmholmgren [email protected] wrote:

You can of course always split out mocked classes into helper files so you
can share them between tests.

On Fri, 4 Sep 2015 at 5:08 am, Ted Sander [email protected]
wrote:

Having less code needs to be carefully balanced with having too much
"magic." Magic is great when it works, but when it doesn't it is a cause
of
a lot of developer angst.

I don't think this savings is worth the added complexity/latency that is
added to the build chain. That said if you want to setup a prototype and
see how it turns out.

—
Reply to this email directly or view it on GitHub
<
https://github.com/fibulwinter/dart-mockito/issues/20#issuecomment-137544441

.

—
Reply to this email directly or view it on GitHub
https://github.com/fibulwinter/dart-mockito/issues/20#issuecomment-137564456
.

[TedSander]

Closing this as transformers are no longer recommended by the dart team