> I think the test name separation by unit test/integration test/micro
test/behaviour test doesn't work, but I'm not sure what's the "sensible"
way to separate them yet like fast/slow/io/non-io? business/technical?structure vs behaviour?
I'm curious about this, because I hear it from time to time.
I have some questions, and we don't have to limit those to Tony, although I'm also interested in his replies:
1. What kind of "doesn't work"? It works for me, so maybe we have different ideas about how it could work or should work.
2. I classify tests in order to better understand all the different kinds of intent and purpose we have when we write them. This helps me decide how to choose which tests to write next. What challenges do you have with all these test classifications?
3. Some people report that there are too many test classifications to understand well. They become confused. I empathize. Why don't you simply ignore those classifications until you need them?
Finally, as for the difference between business and technical tests, when I talk about TDD I tend to focus on technical tests, because that's my context for TDD: to focus on the code. I handle Customer Tests (or business tests) quite differently, and I only sometimes practise what we've called Story-TDD or Acceptance-TDD. I practise it most often when I play the role of Customer for myself, such as on my volunteer projects. I try _very hard_ to clarify this for the people I teach, but I always run the risk that the message doesn't make it through.
-- J. B. (Joe) Rainsberger :: ?:: ::
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
J. B. Rainsberger