Michael Feathers - the deep synergy between testability and good design
Why Stack Overflow recommends it
Stack Overflow users link it when answering unit testing questions where hard-to-test code points to a design problem such as too many responsibilities or heavy use of private methods.
Recommended by 3 people across 3 different months, 2013 to 2017.
Why Software Engineering Stack Exchange recommends it
Software Engineering Stack Exchange users link it when explaining that difficulty writing unit tests signals a design problem, and that testing pushes code toward better structure.
Recommended by 1 people across 1 different months, 2017 to 2022.
What it is
A roughly 50-minute conference talk by Michael Feathers, author of Working Effectively with Legacy Code, on why code that is easy to test tends to be well designed. He walks through examples, including how tests can drive improvements to a parser's design.
What people said
Strong rec Augusto · 2013-07 · Stack Overflow · on “How to unit test a parser which returns 'tell-dont-ask' objects?”
Your design might not be ideal, but it's difficult to know without looking at the code. Something to ask yourself is the Parser hiding too much information, and as a consequence doing too much. I strongly suggest you to watch this presentation from Michael Feather, in which (interestingly) he discusses how to improve the design of a parser using tests, and it looks like the problem he solves is similar to what you're trying to solve. Michael Feathers - the deep synergy between testability and good design [this video]
Recommends ethanfar · 2014-05 · Stack Overflow · on “How to test the interaction between a method and its two helpers?”
The caution you're referring to is rightfully there. There's a very good correlation between testable code and good design (I recommend watching this lecture from Michael Feathers to understand why [this video] ). Using spies tends to be a heads up for design issues since it usually arises from the impossibility of using regular mocks and stubs. It's a little hard to predict from your example, since you're obviously using pseudo names, but it seems that the design of the MyClass class violates the single responsibility principle ( [LINK] ), since it does processing, creation and messaging (3 responsibilities). If you're willing to change your design, so that the processing class ( MyClass ) will
Recommends Opal · 2014-12 · Stack Overflow · on “Grails / Spock: How to mock single method within class where method is called from within the class itself?”
In my opinion this is not a well designed solution. Tests and design walk hand in hand - I recommend this [this video] talk to investigate it better. If there's a need to check if other method was invoked on an object being under test it seems it should be moved to other object with different responsibility. Here's how I would do it. I know how visibility works in groovy so mind the comments. @Grab('org.spockframework:spock-core:0.7-groovy-2.0') @Grab('cglib:cglib-nodep:3.1') import spock.lang.* class MessageServiceSpec extends Specification { def 'test'() { given: def service = new MessageService() def sender = GroovyMock(MessageSender) and: service.sender = sender when: service.sendMessages(['1
Recommends displayName · 2019-03 · Software Engineering Stack Exchange · on “How do you justify more code being written by following clean code practices?”
Let's assume that you are working with class Contact currently. The fact that you are writing another method for validation of email address is evidence of the fact that the class Contact is not handling a single responsibility. It is also handling some email responsibility, which ideally, should be its own class. Further proof that your code is a fusion of Contact and Email class is that you will not be able to test email validation code easily. It will require a lot of maneuverings to reach email validation code in a big method with the right values. See the method viz below. private void LargeMethod() { //A lot of code which modifies a lot of values. You do all sorts of tricks here. //Cod
Cites Ant P · 2017-02 · Software Engineering Stack Exchange · on “How do unit tests facilitate design?”
Not only do unit tests facilitate design, but that is one of their key benefits. Writing test-first drives out modularity and clean code structure. When you write your code test-first, you will find that any "conditions" of a given unit of code are naturally pushed out to dependencies (usually via mocks or stubs) when you assume them in your code. "Given condition x, expect behaviour y," will often become a stub to supply x (which is a scenario in which the test needs to verify the behaviour of the current component) and y will become a mock, a call to which will be verified at the end of the test (unless it's a "should return y ," in which case the test will just verify the return value exp
Cites displayName · 2017-02 · Software Engineering Stack Exchange · on “How do unit tests facilitate design?”
**Heads Up: Youtube video linked.** There is a deep synergy between good design and testing [this video] . In my experience, if you have trouble testing, the design needs fundamental improvement. This is how unit testing essentially facilitates good design.
Cites Matt Messersmith · 2017-11 · Stack Overflow · on “Should I test private methods or only public ones?”
I do not like testing private functionality for a couple of reasons. They are as follows (these are the main points for the TLDR people): Typically when you're tempted to test a class's private method, it's a design smell. You can test them through the public interface (which is how you want to test them, because that's how the client will call/use them). You can get a false sense of security by seeing the green light on all the passing tests for your private methods. It is much better/safer to test edge cases on your private functions through your public interface. You risk severe test duplication (tests that look/feel very similar) by testing private methods. This has major consequences wh
Cites Matt Messersmith · 2017-11 · Stack Overflow · on “What is the best way of testing private methods with GoogleTest?”
There are at least two more options. I'll list out some other options you should consider by explaining a certain situation. Option 4: Consider refactoring your code so that the part you want to test is public in another class. Typically when you're tempted to test a class's private method, it's a sign of bad design. One of the most common (anti)paterns that I see is what Michael Feathers calls an "Iceberg" class. "Iceberg" classes have one public method, and the rest are private (which is why it's tempting to test the private methods). It might look something like this: [LINK] For example, you might want to test GetNextToken() by calling it on a string successively and seeing that it return
Cites Filip Milovanović · 2022-10 · Software Engineering Stack Exchange · on “Tests of 1-Dependency VS Tests of 0-Dependency”
"why are "unit tests" considered so important when they don't really test your application" Perhaps an analogy will help; an isolated unit test is like SpaceX engineers testing one of their Raptor engines [LINK] without hooking it up to an actual rocket. Instead, they hook it up to test equipment which allows them to test the behavior of the engine in isolation, and allows them fine control over the experimental conditions. The engine is the unit under test, and the supporting equipment is, quite literally, a mockup of the other parts of the rocket that connect to the engine. It doesn't do everything that the rocket does. It does, however, have to do everything that's necessary for the purpo