Mosh’s solution to testing CalculateDemeritPoints tests actual returned values; however, I thought this was too specific of a test. If the variable above the speed limit changes, the points calculated will change, meaning you must change the tests. I wrote a solution that only tested that the demerit points were above 0, so the class is open for changes later, but the tests would still determine if the class is returning demerits. Is this too generic of a test?
Certainly. We want to test that the method returns correct results meaning it implements the business rules correctly. If your calculator returned a random number for speeds above the limit your test would pass although you haven’t implemented the calculation according to the law.
Of course you wouldn’t test every speeds from the speed limit to a Bugatti Chiron top speed. Usually you should test edge cases, breaking points, branching points etc.
Ok, maybe I’ve misunderstood not testing implementation. I don’t want to test how, but I do want to test what - even if that means tests would have to change if some variables change?
The tests have to change if the business rules change not if the implementation changes. If the business rules change you’ll usually start with changing the tests and than make the necessary changes to the implementation until your tests are “green”.
Actually implementation will likely change e.g. because you need to restructure your code to implement new features. And the tests give you the confidence that your changes don’t break “old” business rules that are still valid.