3 ms·

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 y

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
      Yes, derived from, but not the same as. I think the best way to think of it is that caching addresses a business requirement, but it is not a business requirement in itself. The business requirement is e.g., n requests per second, and it is up to the programmer to solve it whatever way they want. The requirement is adequately captured in tests that simply pound the external API to make sure it can keep up, which assumes nothing about how it got its performance.
  - taeric 8y ago
    Interestingly, a customer does care that you operate quickly. Such that a relatively got cache becomes a requirement quickly. Of course, this quickly leads to instrumentation for analysis being valuable. And that is, thankfully, easily tested.

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
    Yes, derived from, but not the same as. I think the best way to think of it is that caching addresses a business requirement, but it is not a business requirement in itself. The business requirement is e.g., n requests per second, and it is up to the programmer to solve it whatever way they want. The requirement is adequately captured in tests that simply pound the external API to make sure it can keep up, which assumes nothing about how it got its performance.
- taeric 8y ago
  Interestingly, a customer does care that you operate quickly. Such that a relatively got cache becomes a requirement quickly. Of course, this quickly leads to instrumentation for analysis being valuable. And that is, thankfully, easily tested.