



One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.





Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:

#agile pic.twitter.com/4oT5HE4qs3 Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? #development — Ash Winter (@northern_tester) December 19, 2017

30 replies with ideas tends to indicate that people might be into it.

The List

I thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:

That developers always write unit tests

That developers never write unit tests

That testers can write unit tests for developers

That developers know what unit testing is

That testers know what unit testing is

That a class is a unit to test

That a function is a unit to test

That two people mean the same thing when they say unit

That anyone knows what a unit is in the context of their code

That unit tests fill in the bottom of the test automation pyramid

That unit tests remain in the bottom layer of the test automation pyramid

That unit tests are inherently more valuable than other layers of tests

That unit tests are fast to run

That unit tests are always automated

That lots of unit tests are undoubtedly a very good thing

That unit tests can eradicated non determinism completely

That unit tests are solitary rather than collaborative

That test driven development is about testing

That reading unit tests relay the intent of the code being written

That unit test document the behaviours of code

That when there are unit tests, refactoring happens

That when there are no unit tests, refactoring happens

That you never need to maintain and review unit test suites

If it's not adding value through quick feedback it needs removing or changing.

That unit tests sit outside a testing strategy for a product

Because they exist, the unit tests are actually good

Assertions are actually good. Checking for absence, as opposed to presence

If you have a well designed suit of unit tests you don't need to do much other testing

100% code coverage for a given feature is evidence that the feature works as designed

That code is always clean if it has unit tests

Unit tests are about finding bugs

That there is a unit to test

That a failing test indicates what is wrong

That one problem = 1 failed test

That good unit tests are easy/hard (adapt based on your delivery) to write for non-deterministic functions

"That unit test coverage is irrelevant to manual testing"? aka "Why look at them? They're JUST unit tests, we have to check that again anyways."

That they may/may not believe that is a tester's responsibility to ensure code quality and consistency of the test suite (and that developers may believe the opposite)

That unit tests don't count as "automation" if they do not use the UI

That unit testing allows safe refactoring

That the intent a developer has when they write the thing they call a unit test (guiding the design) is the same as the intent a tester has when they write the thing they call a unit test (discovery and confidence).

That a large number of unit tests can replace integration tests.

That unit tests evaluate the product.

That false negatives ("gaps" or "escapes") in unit tests are a symptom of not having enough unit tests.

Writing unit tests while developing the 'production' code is a waste of time, as the code will change and you'll have to rewrite them.

Having unit tests will prevent bugs

That coverage stats give anything useful other than an indicator of a potential problem area.

When and how often to run them. And how much confidence that actually gives you

That code quality for tests doesn't matter as they're just tests

When to write the unit tests (before/after the 'production' code

The difference between a unit test and and integration test

That how much coverage you get with unit tests says anything about the quality of your test suite

That you don't need additional tests because everything is unit tested

That unit tests are the *only* documentation you need

That they will be shared with the rest of the team

TDD is a testing activity/TDD is a design activity/TDD is both/TDD is neither

That the purpose of unit tests is to confirm a change didn't break something

The list is raw and some entries straddle disciplines as the world is big, fun muddle despite our efforts to compartmentalise. I hope its a useful guide to interactions with developers regarding this layer of testing. Next time a developer asks for an opinion on existing unit tests or help with writing new ones, have a look through this list and challenge your assumptions. After all, illusions about code is our business...

Thanks

Thanks to the following for their contributions*:

Steven Burton

Angie Jones

Gav Winter

James Sheasby Thomas

Dan Billing

Peter Russell

Joe Stead

Colin Ameigh

Marc Muller

Adrian McKensie

Douglas Haskins

Mat McLouglin

Dan North

Josh Gibbs

Marit van Dijk

Nicola Sedgewick

Phil Harper

Joep Schuurkes

Danny Dainton

Gwen Diagram

* If I forgot you, please tell me.















