On Apr 29, 2022, at 10:22 AM, J. B. Rainsberger < me@...> wrote:
? The traditional (XP) view is that so-called "unit" tests verify that the intention of the programmer has been met, while "acceptance" tests verify the intention of the user or customer. For unit tests, I've long since moved to using Hill's term, microtests, which means for me "the kind of unit tests I aspire to write."
And here is where I whine a little. :) "micro" means "small", so could we pretty please use "microtests" to mean "small tests" instead of turning the word into new jargon? We can all acknowledge a general bias towards small tests, but not all our best tests are microtests all the time. Sadly, our audience is routinely hearing "only write microtests or you're a bad person". We can't stop that, but we can slow it down. I'd like to try.
That suggests that size matters - my experience is that it is primarily *speed* and lack of real-world dependencies that are most useful. So the meaning I seek is not that a test is small (whatever that may mean), but that it is super fast (on other of a couple of milliseconds) and tests the project code only - no dependencies on I/O, system clocks, or any other environment behavior. If that includes a large code unit, fine - as long as it is very fast and clearly repeatable. ?I don¡¯t think ¡°microtests¡± captures that meaning. ¡°Unit test¡± can be a problem, as I have had some people use it to mean anything written with an xUnit library. ¡°Pure unit test¡± is the least bad name I have found so far. ----------------- Author, HttpUnit <> and SimpleStub <> Now blogging occasionally at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing! On Apr 29, 2022, at 10:22 AM, J. B. Rainsberger < me@...> wrote:
? It's funny how long the terminology "unit tests" has hung on. Perhaps that's because of its vagueness. When I worked on IBM mainframes, a typical "unit" test covered a single unit of compilation, which was generally the amount of compiled code for which we had enough base registers available: usually 4, 8 or 12K. So as you may imagine it was pretty small. If you were testing more than one such unit, that was integration. If you were testing the whole system, that was a system test. Of course, these were terms used by the testing group, since programmers didn't do testing (other than adhoc) back then. :-)
I didn't know that the term literally originated as referring to compilation units, but that makes immediate sense to me. Modernizing this meaning to "unit of inspection" (since we don't have those limitations as often any more) seems even more natural now.
The traditional (XP) view is that so-called "unit" tests verify that the intention of the programmer has been met, while "acceptance" tests verify the intention of the user or customer. For unit tests, I've long since moved to using Hill's term, microtests, which means for me "the kind of unit tests I aspire to write."
And here is where I whine a little. :) "micro" means "small", so could we pretty please use "microtests" to mean "small tests" instead of turning the word into new jargon? We can all acknowledge a general bias towards small tests, but not all our best tests are microtests all the time. Sadly, our audience is routinely hearing "only write microtests or you're a bad person". We can't stop that, but we can slow it down. I'd like to try.
-- J. B. (Joe) Rainsberger :: ?:: ::
-- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002
|
