Automating checks for "good" unit tests

by thegreendroid   Last Updated May 25, 2017 01:05 AM

There's already a question about How to write good unit tests.

Based on the answers provided there, the key properties of a good unit test -

  • Short
  • Readable and conveys intent instantly
  • Independent
  • Fast
  • Repeatable
  • Tests one thing (SRP)
  • Has a good name

Keeping those properties in mind, how would one go about automating checks for ensuring only "good" unit tests are merged back to the main codebase?

I am absolutely of the opinion that automating these checks is the way to go, if it can be reasonably achieved. There are so many things a reviewer needs to watch out for when accepting a merge request - clean code, design, architecture, clean tests etc. so reducing the burden by automating checks that used to be manual is always welcome.

Answers 1

Lets sort your properties by ease of automated checking:

  • Fast - Most IDE's already tell you this

  • Short - You line count tells you this (so long as you don't abuse white space)

  • Repeatable - Rerunning already tells you this

  • Independent - This could be done by listing what files the test requires, and what they require ...

  • Tests one thing (SRP) - Count your asserts. Is there more than one?

  • Readable - Simple, write an AI that writes code and invite it to the code review. Ask what it thinks.

  • Has a good name - Hope the AI is smarter than humans because even we suck at this.

May 25, 2017 00:39 AM

Related Questions

Integration tests, but how much?

Updated February 28, 2017 08:05 AM

What are the disadvantages of automated testing?

Updated June 23, 2015 09:02 AM

How is code coverage measured?

Updated February 16, 2018 22:05 PM

Systematic study of test automation pyramid

Updated August 07, 2017 17:05 PM