I agree that the naming can be confusing because often the same name means different things to different people. I don't get too hung up on the naming of types of tests (though I love Gpaw's "microtests" because it gets out of the "unit test" mire). Instead, I tray to talk about the meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
- "unit tests" which tested in memory code without any other dependencies
- "database tests" which tested code dependent on the database. This led me to using the Adapter Pattern so I could isolate my unit tests from the database and test only the adapter against a real database.
- "deployed tests" which required the system to be deployed in order to run. These tended to be "story tests," though I found that by delegating from the requirements of the app server (J2EE in those days) to Plain Old Java Objects with the same API, I could implement most of the story tests the same way as unit tests, so "story tests" became another category.
Eventually I had need to call other systems beyond the database, so those became another classification of tests, but done in the same fashion as the database tests.
- George
toggle quoted message
Show quoted text
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
> 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 yetlike 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 :: tdd.training <>?:: jbrains.ca <> ::
blog.thecodewhisperer.com <>
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
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
