Clean Code – How to Write Amazing Unit Tests

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

When and why should you write unit tests, and just how important are they? Take a listen and see what YOU think.

Podcast News

iTunes: AUS Dan G, bryangrove, Criviere, Kasprs, sulhogar, Niil Ohlin (Neil Ilin)
Stitcher Reviews: indiegamer21, makeACaseForCamelCase, athyng, brokenrelay, El_Zilcho

MongoDb and ElasticSearch Ransomware Attacks
http://www.pcworld.com/article/3157417/security/after-mongodb-ransomware-groups-hit-exposed-elasticsearch-clusters.html

Alexa 7 Minute Workout
https://www.amazon.com/Pargee-7-Minute-Workout/dp/B018WUNBE6

Question: Does every programmer spend their nights coding?!

Send us a SASE – http://www.codingblocks.net/swag

Winner of Clean Code for Episode 52
Kevin Kemier – @kevinkemler

Thanks for the post cards from Wroclaw and Gdansk, Poland Rocks!
Community Spotlight: http://www.codingblocks.net/community-spotlight/

• MS DevShow: http://www.codingblocks.net/community-spotlight/community-spotlight-ms-dev-show/
• Cynical Developer: http://www.codingblocks.net/community-spotlight/cynical-developer/
• Zac Braddy: http://www.codingblocks.net/community-spotlight/the-reactionary/

Advice for new programmers? Make something fun and launch!
Mini Code Adventures:

• Yeoman
• Markov Chains

Unit Tests

Three laws of TDD

1. You may not write production code until you have written a failing unit test
2. You may not write more of a unit test than is sufficient to fail, and compiling is failing
3. You may not write more production code than is sufficient to pass the currently failing test

Keeping Tests Clean

Problem with this approach – test code could outgrow your prod code and become unmanageable
Is dirty test code better than no test code?

• Tests must change as the production code changes
• The dirtier the tests, the harder they are to change
• Tests can become a liability due to technical debt of the dirtiness

Abandoning test code has the following consequences

• Production code defects rise
• Fear of changing code increases
• Cleaning / refactoring code descreases due to lack of confidence (Code rot!!!)

Test code is as important as production code – it should be treated as a first class citizen and should be as clean as production code.

Tests Enable the -ilities

• Tests are what keep your production code flexible, maintainable and reusable.
• Tests allow you to make changes to code without fear.
• Tests enable change.
• Tests enable improving architecture.

Without tests, your code base rots.

Clean Tests

• Readability
• More important in Unit Tests than in production code?
• Clarity
• Simplicity
• Density of expression

Much like writing great functions, if you have to learn a ton of details to make heads or tails of a test, it can be improved.

Build – Operate – Check Pattern

Build – builds up the test data
Operate – works on the test data
Check – ensure the operation yielded the expected results

Great example in the book of refactoring an ugly test to a clean one

Domain Specific Testing Language

• Tests are written in specific ways for various testing platforms
• Helps readability

Double Standard?

Interesting points made on asserts in line with values…
Author chose to do upper / lower combination of characters in an initialism to indicate whether the particular test result should have been true or false

Unit tests are often not held to the same standard in terms of performance

• StringBuilder in production
• String Concatenation in tests

One assert per test

• Makes tests very easy to read
• Given, When, Then naming
  Author actually prefers multiple asserts in some scenarios (XML example from book)
  Author notes that single assert is a good guideline
  Should try to minimize the number of asserts

Single concept per test

More important than a single assert per test
Ensures that your tests are laser focused and not testing miscellaenous (non-related) things

FIRST

• (F)ast – tests should be fast / run quickly
• (I)ndependent – tests should NOT depend on each other – tests should be able to be run in any order they like
• ®epeatable – they should be repeatable in ANY environment without need for any specific infrastructure
• (S)elf-validating – they should have a boolean output – pass or fail, nothing else
• (T)imely – they need to be written in a timely fashion – just before the production code is written – ensures they are easy to code against

Importance

Unit Tests are as important if not moreso than the production code they’re for becasue they allow you to make changes confidently and without fear. They allow you to mold your code over time to improve flexibility / maintainability.

Resources we Like

• Clean Code
• Clean Code for JS

Tips of the Week

• Joe: Glyphfriend from Rion (intellisense previews of icons) and https://github.com/workshopper/learnyounode”>Learn You Node from ju66ernaut
• Allen: Visual Studio – Increase / Decrease Font Size with
  ctrl + shift > <
• Michael: Structuring unit tests. A combination of Roy Osherove’s and Phil Haack’s recommendation
  
  Outlaw's Test Format

  C#

  [TestFixture] public class CustomerTests { [TestFixture] public class GetFullName { [Test] public void GetFullName_WhenMiddleNameIsBlank_ReturnsNameAsFirstSpaceLast() { // Arrange ... // Act ... // Assert ... } } [TestFixture] public class GetLastName { [TestCase("Outlaw", "Outlaw")] [TestCase("Underwood", "Underwood")] [TestCase("Zack", "Zack")] public void GetLastName_WhenLastNameHasBeenSet_ReturnsTheLastName(string testcase, string expect) { // Arrange var customer = new Customer { lastname = testcase }; // Act var result = customer.GetLastName(); // Assert Assert.AreEqual(expect, result); } } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

  [TestFixture] public class CustomerTests { [TestFixture] public class GetFullName { [Test] public void GetFullName_WhenMiddleNameIsBlank_ReturnsNameAsFirstSpaceLast() { // Arrange ...   // Act ...   // Assert ... } }   [TestFixture] public class GetLastName { [TestCase("Outlaw", "Outlaw")] [TestCase("Underwood", "Underwood")] [TestCase("Zack", "Zack")] public void GetLastName_WhenLastNameHasBeenSet_ReturnsTheLastName(string testcase, string expect) { // Arrange var customer = new Customer { lastname = testcase };   // Act var result = customer.GetLastName();   // Assert Assert.AreEqual(expect, result); } } }

• http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html
• http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx/
• https://github.com/nunit/docs/wiki/TestCase-Attribute
• https://github.com/nunit/docs/wiki/TestCaseSource-Attribute

Show summary

Chapter 9 – Clean Code’s Unit Tests
Unit test code is as important as production code because they allow you to make changes confidently and correctly, improving your flexibility and maintainability over time