You should remove tests that are not testing the unit in question ( or move them to another unit). The article mentions testing X=5. Is not worth while testin

You should remove tests that are not testing the unit in question ( or move them to another unit). The article mentions testing X=5. Is not worth while testing. It depends on your unit. If the unit is calculator class, then testing this simple function is may be worth testing. If the class is highly level biz rule it may not add any value. If this test is testing an parser parsing X=5 as example for X=<value> sure. You must test this trivial case as well. Think about unittests as logs of debug sessions for this particular class that you would produce to prove a certain point about your code. Keep them simple. Easy to understand. If they fail the failure should explain the failure. You need to much time analysing the failure of your unittest. Redesign them and/or your code to explain failure better. I think the author has probably seen spaghetti unittests to many times - I.e. unittests that don't follow a purpose - just trying to hit code coverage without the intention to prove a rule about the code. also, the advise adjusting code for unittest destroys your architecture is completely wrong. The better your code supports your tests the better the architecture will be. it will be more flexible and has already two use case. The real biz case and the case of unittest. This makes your architecture more robust against change.