DEV Community

Cover image for How I Survived the Zombie Apocalypse
Maxi Contieri
Maxi Contieri

Posted on • Edited on • Originally published at maximilianocontieri.com

How I Survived the Zombie Apocalypse

#oop #tdd #testing #tutorial

Selecting great test cases is very hard. Unless you summon the undead.

The Problem

Software Testing is a novel discipline for most developers.

Quality Assurance Engineers have great methodologies for use cases creation.

Besides, Test-Driven Development (TDD) technique pushed developers into test writing world. (Not testing world because TDD is not a testing technique).

But we are not ready yet.

mcsee

How to Squeeze Test Driven Development on Legacy Systems

Maxi Contieri ・ Nov 26 '20

#oop #tutorial #tdd #legacy

TDD Personal Journey

I came across TDD back in 2005. I fell in love with XUnit regressions, domain discovery and full coverage.

TDD is an incredible technique but deciding what to test is cumbersome.

I wrote TDD tests in a chaotic way for several years.

I'll summarize some things I learnt these years hoping to spare some time to new developers.

The solutions

Learn to differentiate Test Case against Test Data.

Most programmers love data and instantiation, and have difficulties dealing with abstract concepts.

They rush to create test data missing the big picture of choosing relevant cases.

Choosing accurate data representing test cases should be straightforward. The opposite is not true.

Equivalence Partitioning is a technique for picking right ambassadors
partitioning all possible cases into a finite number of equivalence classes.

You can reasonably assume that a test of a representative value of each class is equivalent to a test of any other value.

Number the tests

If you are developing TDD way creation order shows how you approached the problems.

First cases should be easy to understand and very low coupled.

Baby Steps require we slowly increment our test complexity so we can gradually cope with it. Early green light is a priceless feedback.

Pick Zombie representant

Zombie testing is an acronym for:

Z – Zero

O – One

M – Many (or More complex)

B – Boundary Behaviors

I – Interface definition

E – Exercise Exceptional behavior

S – Simple Scenarios, Simple Solutions

Example

Let's create an email message T.D.D. Way.

One behavior at a time!

Let's start from an empty test class:

TestCase subclass: #EmailMessageTest
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Zombies'
Enter fullscreen mode Exit fullscreen mode

First test will be our (Z)ero. Since we are working TDD, we have not defined EmailMessage class yet.

test01ZeroRecipients

    self deny: (EmailMessage forRecipients: Array new) isValid
Enter fullscreen mode Exit fullscreen mode

name test01ZeroRecipients is composed by

  • a prefix test mandatory in many testing frameworks. (mandatory)

  • a sequential order (to incrementally show the learning/testing procedure). (optional)

  • Zero/One/Many to represent zombies. (optional)

  • a functional description (mandatory)

We start denying (asserting false) our first email will be valid. (since there are no recipients).

(denying is equal to asserting for not but clearer to read and avoids double negatives).

We run our first test.

EmailMessage class is not defined

Object subclass: #EmailMessage
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'TDD-Zombies'
Enter fullscreen mode Exit fullscreen mode

forRecipients: (the constructor)

forRecipients: recipients 

    ^self new initializeForRecipients: recipients
Enter fullscreen mode Exit fullscreen mode

The constructor creates the instance and initializes with the essence (no anti-pattern setters and no mutation from scratch).

The private initializer

initializeForRecipients: emailRecipients 

    recipients := emailRecipients.
Enter fullscreen mode Exit fullscreen mode

initializer sets the private attribute.

This is the first (good enough) implementation for isValid.

isValid
     ^false
Enter fullscreen mode Exit fullscreen mode

isValid is hardcoded to false.

This is one of TDD values. The simplest solution should be hardcoded.

First test passes!!!

Let's go for the (O)ne.

test02OneRecipient

    self assert: (EmailMessage forRecipients: (Array with: 'john@example.com')) isValid.
Enter fullscreen mode Exit fullscreen mode

Test does not work since we hardcoded it to false in previous step.

We change isValid implementation.

isValid
     ^recipients notEmpty
Enter fullscreen mode Exit fullscreen mode

This condition is more general. Now test01 and test02 work!

Let's add new protocol to test02. It should be a different test case but we will overload test02 so we stick to one test per zombie.

test02OneRecipient

    self assert: (EmailMessage forRecipients: (Array with: 'john@example.com')) isValid.
    self assert: (EmailMessage forRecipients: (Array with: 'john@example.com')) plain = 'to: john@example.com'.
Enter fullscreen mode Exit fullscreen mode

plain message will return plain text from email. let's implement it.

plain
     ^'to: ' , recipients first.
Enter fullscreen mode Exit fullscreen mode

We concatenate to: header with the first recipient. Hardcoded.

(ZO) tests are ready. Let's go for the (M)any.

test03ManyRecipients

    | message |
    message := (EmailMessage forRecipients:
 (Array with: 'john@example.com' with: 'jane@example.com' with: 'lucas@example.com')).

    self assert: message plain = 'to: john@example.com,jane@example.com,lucas@example.com'.
    self assert: message isValid
Enter fullscreen mode Exit fullscreen mode

At this point is harder to fake it than to make it. This is a hint we should refactor and make a generic solution instead of hardcoding.

Many is represented by a 3 elements collection. isValid is working but plain isn't.

plain
     ^(recipients inject: 'to: ' into: [:plainText :address | plainText, address ,' ,' ]) allButLast
Enter fullscreen mode Exit fullscreen mode

This idiom iterates over recipients (a private attribute, no getters), inserting a comma (,) and removing last one (allButLast). Since we have no explode.

3 tests working! (ZOM)

We should tackle (B)oundaries.

test04BoundaryRecipients

    | recipients |
    recipients := OrderedCollection new.
    1 to: 10 do: [:index | recipients add: ('john', index asString, '@example.com')].

    self deny: (EmailMessage forRecipients: recipients) isValid
Enter fullscreen mode Exit fullscreen mode

We create 10 different emails john1@example.com, john2@example.com, ..., john10@example.com.

We decide 10 is an arbitrary upper limit for recipients size for this exercise.
Message with 10 recipients is not valid.

isValid
     ^recipients notEmpty and: [recipients size < 10]
Enter fullscreen mode Exit fullscreen mode

This condition now checks for lower limits and upper ones. it is equal to:

isValid
     ^recipients size between: 1 and: 9
Enter fullscreen mode Exit fullscreen mode

Since we have full coverage we can change implementation any time!

ZOMB in. It is the time for (I)nterfaces checking.

test05InterfaceDefinition

    self should: [ EmailMessage forRecipients: 1 ] raise: Exception
Enter fullscreen mode Exit fullscreen mode

We try to create a message with an integer which violates our interface, therefore it should raise an exception.

forRecipients: recipients 

    recipients do: [:eachAddress | 
        eachAddress isString
            ifFalse: [ self error: (eachAddress , ' is not a valid recipient')]].

    ^self new initializeForRecipients: recipients
Enter fullscreen mode Exit fullscreen mode

We validate addresses upon creation. No invalid objects here!

ZOMBI here ! How about (E)xceptional behaviour?

test06ExceptionalBehavior

    self should: [EmailMessage forRecipients: (Array with: 'john@example.com' with: 'john@example.com')] raise: Exception
Enter fullscreen mode Exit fullscreen mode

Duplicates are invalid according to our domain. Let's check them!

forRecipients: recipients 

recipients do: [:eachAddress | 
    eachAddress isString
        ifFalse: [ self error: (eachAddress , ' is not a valid recipient')]].
    (recipients asSet size = recipients size)
        ifFalse: [self error: 'Duplicates'].

    ^self new initializeForRecipients: recipients
Enter fullscreen mode Exit fullscreen mode

We check for duplicates mapping our recipients to a Set and checking both sizes. Not the most performant way.

We need to keep the example working and avoid premature optimization. With all tests running we can optimize code.

mcsee

Code Smell 20 - Premature Optimization

Maxi Contieri ・ Nov 8 '20

#oop #developing #coding #codesmell

How about readability? Method is too ugly. Let's do TDD step 3: Refactor.

forRecipients: recipients 

     self assertAllAddressesAreValid: recipients.
     self assertThereAreNoDuplicates: recipients.        
    ^self new initializeForRecipients: recipients
Enter fullscreen mode Exit fullscreen mode

That's better!

Last test! (S)imple Scenarios.
In this small piece there's no need. We can add one redundant way for teaching purposes:

test07SimpleScenarios

    self assert: (EmailMessage forRecipients: (Array with: 'john@example.com')) plain =     'to: john@example.com'
Enter fullscreen mode Exit fullscreen mode

And that's it.
We have our model built with TDD and great confidence. Full coverage and no gold plating!.

  • No empty constructors
mcsee

Code Smell 13 - Empty Constructors

Maxi Contieri ・ Nov 1 '20

#codenewbie #oop #beginners #coding

  • Model is ummatable

  • No setters

  • No getters

  • No accidental ifs

mcsee

How to Get Rid of Annoying IFs Forever

Maxi Contieri ・ Nov 9 '20

#oop #programming #codenewbie #tutorial
  • No Nulls
mcsee

Code Smell 12 - Null

Maxi Contieri ・ Oct 31 '20

#codenewbie #tutorial #oop

Conclusions

With these tips we can do very basic test writing.

That will be enough for TDD.

TDD does no replace Quality Assurance process and QA Engineers would work together with developers to learn from each other.

Developing software is a human and collaborative activity.

Let's enjoy it together!

Credits

Photo by Yohann LIBOT on Unsplash

Top comments (0)

Read next

under2wenty profile image

Provide storage for the IT department testing and training

Precious Oladele -

sarahthomasdev profile image

How to Perform Google Pay Testing? (Detailed Test Scenarios)

Sarah Thomas -

shinetechsoftwareinc profile image

Bridging the Gap: A Case Study on Synchronizing Shopify and Microsoft Dynamics GP

Shinetech Software -

lazypro profile image

Apache Paimon Playground ft. Flink and Trino

ChunTing Wu -