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, (TDD) technique pushed developers into test writing world. . Test-Driven Development (Not testing world because TDD is not a testing technique) But we are not ready yet. TDD Personal Journey I came across TDD back in 2005. I fell in love with regressions, domain discovery and full coverage. XUnit TDD is an incredible technique but deciding to test is cumbersome. what 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 missing the big picture of choosing . test data relevant cases Choosing representing should be straightforward. The opposite is not true. accurate data test cases is a technique for picking right partitioning all possible cases into a finite number of equivalence classes. Equivalence Partitioning ambassadors 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. require we slowly increment our test complexity so we can gradually cope with it. Early green light is a priceless feedback. Baby Steps Pick Zombie representant is an acronym for: Zombie testing 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: subclass: instanceVariableNames: classVariableNames: poolDictionaries: category: TestCase #EmailMessageTest '' '' '' 'Zombies' First test will be our (Z)ero. Since we are working TDD, we have not defined class yet. EmailMessage test01ZeroRecipients deny: ( forRecipients: new) isValid self EmailMessage Array name test01ZeroRecipients is composed by a prefix mandatory in many testing frameworks. ( ) test 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 but clearer to read and avoids double negatives). asserting for not We run our first test. class is not defined EmailMessage subclass: instanceVariableNames: classVariableNames: poolDictionaries: category: Object #EmailMessage '' '' '' 'TDD-Zombies' (the constructor) forRecipients: forRecipients: recipients 

    ^ new initializeForRecipients: recipients self The constructor creates the instance and initializes with the essence (no anti-pattern setters and no mutation from scratch). Nude Models - Part I : Setters Is it Crystal Clear for Everybody That a Date Should Not Mutate? The initializer private initializeForRecipients: emailRecipients 

    recipients := emailRecipients. initializer sets the private attribute. This is the first (good enough) implementation for . isValid isValid
     ^ false is hardcoded to . isValid false This is one of TDD values. The simplest solution should be hardcoded. First test passes!!! Let’s go for the (O)ne. test02OneRecipient assert: ( forRecipients: ( with: )) isValid. self EmailMessage Array 'john@example.com' Test does not work since we hardcoded it to in previous step. false We change implementation. isValid isValid
     ^recipients notEmpty 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 assert: ( forRecipients: ( with: )) isValid. assert: ( forRecipients: ( with: )) plain = . self EmailMessage Array 'john@example.com' self EmailMessage Array 'john@example.com' 'to: john@example.com' message will return plain text from email. let’s implement it. plain plain
     ^ , recipients first. 'to: ' We concatenate header with the first recipient. Hardcoded. to: (ZO) tests are ready. Let’s go for the (M)any. test03ManyRecipients

    | message |
    message := ( forRecipients:
 ( with: with: with: )). assert: message plain = . assert: message isValid EmailMessage Array 'john@example.com' 'jane@example.com' 'lucas@example.com' self 'to: john@example.com,jane@example.com,lucas@example.com' self At this point . This is a hint we should refactor and make a generic solution instead of hardcoding. is harder to fake it than to make it Many is represented by a 3 elements collection. is working but isn’t. isValid plain plain
     ^(recipients inject: into: [:plainText :address | plainText, address , ]) allButLast 'to: ' ' ,' This idiom iterates over recipients (a private attribute, no getters), inserting a comma (,) and removing last one ( ). Since we have no . allButLast explode Nude Models - Part II : Getters 3 tests working! (ZOM) We should tackle (B)oundaries. test04BoundaryRecipients

    | recipients |
    recipients := new. to: do: [:index | recipients add: ( , index asString, )]. deny: ( forRecipients: recipients) isValid OrderedCollection 1 10 'john' '@example.com' self EmailMessage 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 This condition now checks for lower limits and upper ones. it is equal to: isValid
     ^recipients size between: and: 1 9 Since we have full coverage we can change implementation any time! ZOMB in. It is the time for (I)nterfaces checking. test05InterfaceDefinition should: [ forRecipients: ] raise: self EmailMessage 1 Exception If we try to create a message with an integer with are violating our interface, therefore it should raise an exception. forRecipients: recipients 

    recipients do: [:eachAddress | 
        eachAddress isString
            ifFalse: [ error: (eachAddress , )]].

    ^ new initializeForRecipients: recipients self ' is not a valid recipient' self We validate addresses upon creation. No invalid objects here! ZOMBI here ! How about (E)xceptional behaviour? test06ExceptionalBehavior should: [ forRecipients: ( with: with: )] raise: self EmailMessage Array 'john@example.com' 'john@example.com' Exception Duplicates are invalid according to our domain. Let’s check them! forRecipients: recipients 

recipients do: [:eachAddress | 
    eachAddress isString
        ifFalse: [ error: (eachAddress , )]].
    (recipients asSet size = recipients size)
        ifFalse: [ error: ].

    ^ new initializeForRecipients: recipients self ' is not a valid recipient' self 'Duplicates' self 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. How about readability? Method is too ugly. Let’s do TDD step 3: Refactor. forRecipients: recipients assertAllAddressesAreValid: recipients. assertThereAreNoDuplicates: recipients.         
    ^ new initializeForRecipients: recipients self self self 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 assert: ( forRecipients: ( with: )) plain = self EmailMessage Array 'john@example.com' 'to: john@example.com' And that’s it. We have our model built with TDD and great confidence. Full coverage and no gold plating!. No empty constructors Model is ummatable No setters No getters No accidental ifs No Nulls 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! Part of the objective of this series of articles is to generate spaces for debate and discussion on software design. We look forward to comments and suggestions on this article. Also published on Hashnode .

Discovery

How to Find the Stinky Parts of Your Code (Part IV)

How to Find the Stinky Parts of Your Code (Part III)

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Book Author

Too Long; Didn't Read

Zombie Testing: One Behavior at a Time

Zombie Testing: One Behavior at a Time

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

10 Predictions About the Future of Finance

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Zero People Charged With Online Pirating, Swedish Prosecutor's Office Reports

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps