Skip to main content

Testers Guide to Myths of Unit Testing


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:
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.





Comments

  1. Awesome list! Now how do we dispel these myths.

    ReplyDelete

Post a Comment

Popular posts from this blog

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…

Why do Testers become Scrum Masters?

It was late and I was stuck on a train, so I pondered on the question of why do testers often (in my experience) become Scrum Masters. Its a very dear question to me, as its been a big part of my career journey In fact, I've been there and back again. Tester to supposed-to-be-testing-but-being-a-Scrum-Master to Scrum Master, back to Tester and very happy thank you.

I encapsulated my reasoning in the following:
Long train delay, decided to think about a thing. :) Why do testers (in my world anyway) often become Scrum Masters? #testing#agile#scrumpic.twitter.com/FGGXFiBGz1 — Ash Winter (@northern_tester) February 13, 2018The tweet got a lot of traction, and generated a couple of interesting threads which made me think.
Great list. Personally I think that as a scrum master I can add even more towards the goal of quality. — Christian Kram (@chr_kram) February 13, 2018 Perhaps part of the reason for the transition is a growing appreciation of where quality has its roots? If testing i…