Profile picture
Michael Bolton @michaelbolton
, 10 tweets, 2 min read Read on Twitter
We're into a tricky area here, since "acceptance tests" and "unit tests" are not *tests* as such. (I recognize that this is controversial, but please hear me out I DO acknowledge the value of them, too, but let's get clear on what I'm talking about here.)
First, "acceptance tests". Most of the time, when they've become artifacts, they represent *examples* of what the product should do. The process of *actually examining* the product to assert that it behaves in a way consistent with the example is a test. And yet...'s a pretty weak test; less like an experiment or an exploration; more like a demonstration to show that the product CAN work. Interestingly, though, the process of *developing* an acceptance test has more testing content in it, since thought experiments are going on.
Nonetheless, those thought experiments *don't* result in an improved product unless someone changes their minds or sharpens their ideas. In other words, the testing does not make the product better, even though it's part of a process that does make a product better.
One reason I want to emphasize this is to give credit where credit is due: to the people who actually put the quality into the product; those who actively build it; those who manage the product. I don't do that. I'm delighted to say, modestly, that I help them do it.
Now, "unit tests" and "unit testing". There are things that people call unit tests; we in Rapid Software Testing, we call them unit checks *when they can be performed algorithmically*; *when.they are encoded*. They are not tests as such, to us; they are *parts* of a test.
Unit testing (again, to us) is an activity of exploration and experimentation focused on units and unit-level risk. It may (maybe should) involve unit checks, but you can do unit testing without unit checks (example: stepping through the unit via the debugger to learn stuff).
Nonetheless: whether you're unit testing by applying checks or by more direct interaction with the product, it doesn't improve the product *unless you change the product code* or *change your mind* about some aspect of developing the product. Testing *on its own* doesn't do that.
Also, you can set out to improve without acceptance tests and without unit tests — although you'd almost certainly need testing in some form to discover whether it had *actually* improved or (perhaps more significantly) got worse.
So, to sum up: I think we'd agree that a testing mindset (whether taken by some person called "tester" or not) *informs* making a product better. A testing mindset and testing activity *on their own* don't make a product better; developers and development do that. Testing helps.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Michael Bolton
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!