Re:Kent Beck: “I get paid for code that works, not for tests...
by olavk on Thursday December 08, 2016 @05:58PM
(#13135094)
Yeah you can have bad architecture with or without tests, having tests does not mean you don't have to think about design! I disagree that tests lock you down though, it really depends on how they are written.
Re:Kent Beck: “I get paid for code that works, not for tests...
by wvenable on Thursday December 08, 2016 @06:26PM
(#13135299)
You can't have unit tests that don't lock you down to a particular structure of units. That's really the definition of unit testing.
I'm not saying anything about bad architecture. You have a good architecture for today's requirements that is a bad architecture for next year's requirements. Tests lock you down to whatever your first architecture is.
Re:Kent Beck: “I get paid for code that works, not for tests...
by olavk on Friday December 09, 2016 @02:45AM
(#13137344)
I tend to avoid the term unit-test since there is some disagreement about what "unit" mean. Some think it means testing everything down to the level of individual private methods. This will indeed lock you down. And if it paired with extensive "mocking", where you only ever test that method A calls method B when invoked, then yes, you have locked your self down and you wont get a lot of value from the tests.
I prefer automated tests of larger units or subsystems, and testing against requirements, protocols and specifications rater than implementation details would change. Of course anything will change over time, but I believe this kind of tests provides higher value and lives longer.
I've had to completely redesign entire subsystems; break down components into different pieces; move code between different layers; etc.
Honestly as a manager nothing bothers me more than developers who try and patch complex changes into existing systems without re-thinking how it affects everything else. I have to re-factor a project that's a total mess because code was added but not removed or changed over the course of some very big requirements changes. I'm sure all the tests pass but it's impossible to follow now.
The problem with unit tests is it adds an extra layer of friction on making changes that benefit the product. You are actively discouraged from changing your design from your initial assumptions! This change friction can be seen as a benefit if you need all your interfaces to be stable (like with a library). But it's a trade off and it's not appropriate everywhere.