3 ms·

Overall, try to constantly ask yourself a question: does this test verify some business requirement? If the answer is no, remove it. The most valuable tests are

Overall, try to constantly ask yourself a question: does this test verify some business requirement? If the answer is no, remove it. The most valuable tests are always the tests that have at least some connection to the business requirements your code base is ought to address. Not surprisingly, such tests also fall into the formal definition I brought in the beginning of this article: they are likely to give a protection against regression errors and they are unlikely to turn red without a good reason. Easier said than done. Let's say I'm writing a game AI and I wrote a test that confirms that ogres can eat humans but cannot eat other ogres. Is this testing a business requirement?

sudhirj 8y ago
Yes that’s exactly what it is. If you business is selling a game that works, ogres not eating other ogres is a requirement for your game to be considered bug free and sell well. (YMMV, depending on who your audience is ogre cannibal feat might also be fun). This is as opposed to testing that that the eat method on the ogre only accepts an instance of the Human class. If you do that you’ll have a brittle system on your hands, and when your ogres decide to eat horses (business decision) you’ll have to change a lot of tests and will instead procrastinate by writing a blog post about why TDD sucks.
- domlebo70 8y ago
  A good type system makes the 2nd change you proposed a joy to make.
  - sudhirj 8y ago
    Oh, absolutely. A good type system also makes unnecessary to write tests asserting that your implementation uses exact / concrete types. A good type system would allow you to have a clean and sane 'Eatable' concept (interface / trait / protocol) that you can use and assert instead.
lgessler 8y ago
I think you might be taking "business requirement" in too narrow a sense. Maybe a better expression would be "external behavioral requirement", i.e. something your program has to "appear to do" from some outside perspective.
- Waterluvian 8y ago
  The problem with this advice and answer is that we are back to square one: pretty much anything can be explained away as a business requirement.
  - lgessler 8y ago
    Hm, I don't quite understand. Caching, for example, seems like it's pretty hard to construe as business logic, at least under my definition above. Suppose you have an HTTP server that caches the past N documents it's seen in memory and otherwise uses the OS to retrieve the file. But a consumer doesn't care about how the document was found, it just cares about the document. In this example you might say that the caching mechanism needs to be tested also. I'd agree that you should test the mechanism, but this does not necessarily mean that you need to test its functions: you could construct a variety of tests using just the `get(...)` function or whatever faces the consumer, and test sequences that you think might produce a bad response, which was in turn produced by a bad cache. The internal mechanism is probed by the tests, but in a way that assumes no knowledge of its guts and would therefore still work if this caching mechanism were removed or replaced.
    - ivan_gammel 8y ago
      Caching is derived from business requirements, of course. You'd expect lower time of response on cache hits than on cache misses. There are at least couple ways to test it: counting FS access under assumption it is the bottleneck or real performance testing. Both tests would vergiy some version of business requirements.
      - lgessler 8y ago

sudhirj 8y ago

Yes that’s exactly what it is. If you business is selling a game that works, ogres not eating other ogres is a requirement for your game to be considered bug free and sell well. (YMMV, depending on who your audience is ogre cannibal feat might also be fun). This is as opposed to testing that that the eat method on the ogre only accepts an instance of the Human class. If you do that you’ll have a brittle system on your hands, and when your ogres decide to eat horses (business decision) you’ll have to change a lot of tests and will instead procrastinate by writing a blog post about why TDD sucks.

domlebo70 8y ago
A good type system makes the 2nd change you proposed a joy to make.
- sudhirj 8y ago
  Oh, absolutely. A good type system also makes unnecessary to write tests asserting that your implementation uses exact / concrete types. A good type system would allow you to have a clean and sane 'Eatable' concept (interface / trait / protocol) that you can use and assert instead.

lgessler 8y ago

I think you might be taking "business requirement" in too narrow a sense. Maybe a better expression would be "external behavioral requirement", i.e. something your program has to "appear to do" from some outside perspective.

Waterluvian 8y ago
The problem with this advice and answer is that we are back to square one: pretty much anything can be explained away as a business requirement.
- lgessler 8y ago
  Hm, I don't quite understand. Caching, for example, seems like it's pretty hard to construe as business logic, at least under my definition above. Suppose you have an HTTP server that caches the past N documents it's seen in memory and otherwise uses the OS to retrieve the file. But a consumer doesn't care about how the document was found, it just cares about the document. In this example you might say that the caching mechanism needs to be tested also. I'd agree that you should test the mechanism, but this does not necessarily mean that you need to test its functions: you could construct a variety of tests using just the `get(...)` function or whatever faces the consumer, and test sequences that you think might produce a bad response, which was in turn produced by a bad cache. The internal mechanism is probed by the tests, but in a way that assumes no knowledge of its guts and would therefore still work if this caching mechanism were removed or replaced.
  - ivan_gammel 8y ago
    Caching is derived from business requirements, of course. You'd expect lower time of response on cache hits than on cache misses. There are at least couple ways to test it: counting FS access under assumption it is the bottleneck or real performance testing. Both tests would vergiy some version of business requirements.
    - lgessler 8y ago