> So near the physical boundary of the system there is a layer that requires fiddling. It is useless to try to write tests first (or tests at all) for this layer.
Maybe I can see what he's trying to say, but I don't think statement alone is accurate.
For the GUI i.e. at the human boundary of the system, the most value (especially to stop regression and catch side affects) is often added with tests e.g. automated tests which perform some user function in the GUI and assert the results.
Another physical boundary of the system is a database. Writing tests which cross this boundary add a lot of value too.
I'd favour these tests which hit the boundaries and go over them, over a codebase with only unit tests and endless mocking any day of the week.
Also these type of tests can be written first. We do it.
Unit tests don't have to test everything... just the units. Integration tests should be testing the interactions between different modules. And system tests should be the whole stack top-to-bottom. It ends up looking like a pyramid.
Yes thank you I know the testing pyramid. But testing should concentrate on what adds value and a zillion unit tests, with everything mocked often don't. Infact they can be a distraction from the bigger picture. Rather than rules, methodologies etc. we should TWMS - Test What Makes Sense. Or even better TWAV - Test What Adds Value. Or DTFTS - Don't Test For Testings' Sake.
If I understood correctly I think that's what Uncle Bob was trying to argue for in this blog post.
I don't think having 3-4 tests per LOC is such a bad thing. Far more testing goes into the sqlite codebase and I think it'd be hard to argue that it could have been better if the developers had stopped wasting their time and concentrated on what added value.
Comments
Maybe I can see what he's trying to say, but I don't think statement alone is accurate.
For the GUI i.e. at the human boundary of the system, the most value (especially to stop regression and catch side affects) is often added with tests e.g. automated tests which perform some user function in the GUI and assert the results.
Another physical boundary of the system is a database. Writing tests which cross this boundary add a lot of value too.
I'd favour these tests which hit the boundaries and go over them, over a codebase with only unit tests and endless mocking any day of the week.
Also these type of tests can be written first. We do it.
Unit tests don't have to test everything... just the units. Integration tests should be testing the interactions between different modules. And system tests should be the whole stack top-to-bottom. It ends up looking like a pyramid.
Yes thank you I know the testing pyramid. But testing should concentrate on what adds value and a zillion unit tests, with everything mocked often don't. Infact they can be a distraction from the bigger picture. Rather than rules, methodologies etc. we should TWMS - Test What Makes Sense. Or even better TWAV - Test What Adds Value. Or DTFTS - Don't Test For Testings' Sake.
If I understood correctly I think that's what Uncle Bob was trying to argue for in this blog post.
I don't think having 3-4 tests per LOC is such a bad thing. Far more testing goes into the sqlite codebase and I think it'd be hard to argue that it could have been better if the developers had stopped wasting their time and concentrated on what added value.