Replies: 2 comments
-
http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
We'll often start with production code and test code that is structured similarly. Therefore we'll often want to take a pre-existing test suite written in solitary style automock, and convert it to sociable. |
Beta Was this translation helpful? Give feedback.
-
Released in version v3.0.0. Thanks @soryy708! |
Beta Was this translation helpful? Give feedback.
-
Is there an existing issue for this?
Is your feature request related to a problem? Please describe it
Automock as it is right now is great for solitary unit tests, but I often have a problem. When I refactor production code, I sometimes want to extract a new class to structure things better. However, because Automock assumes that a unit is only a single class, it makes it hard to change the existing unit tests to correctly use the new class. The conceptual unit didn't change, it's only a structural refactor, so it shouldn't be mocked.
It's inconvenient to work-around it right now, with:
Describe the solution you'd like
I'd like to be able to conveniently define which classes should not be mocked, because they're part of the unit under test.
Maybe something like:
What is the motivation / use case for changing the behavior?
https://martinfowler.com/bliki/UnitTest.html
It would be great to support classicist strategies.
https://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html
I think coupling the tests to the classes structure too tightly is undesireable because it can lead to fragile tests.
http://xunitpatterns.com/Fragile%20Test.html
Beta Was this translation helpful? Give feedback.
All reactions