logo
Articletdd

Kickoff your first TDD cycle

Views: 420 Created: 2019-04-13 Read time: 5 minutes
Post Preview
Tags:

1)     Preface

TDD is one of these techniques that everyone knows about, but only a few percent actually use it every day in coding. People have different excuses: it takes to long to get proficient at, no one cares about unit tests in general in my organisation, or simply I do not know where or how to start. In this article, we will be focusing on that last pickle that developers are faced with.

 

2)     Use mind maps to kickoff your tdd cycle

Before we even get into the first strategy, I will try to introduce a straightforward but powerful technique that helps in tackling any kind of problem. It engages both left and right side of your brain and has worked wonders for me in the industry, TDD tackling included.

The strategy is called mind mapping. It basically boils down to finding the most significant piece of paper or whiteboard available and dumping all the content of your brain into it. There are some rules, though:

 

Summary

 

       Your imagination is as big as the piece of paper/whiteboard you are working on. The smaller the area, the weaker the final solution.

       The core problem should lie in the centre. Should bring the most attention. The more crazy, funny, eye-catching, the better.

       Use a different colour for each branch.

       Do not exceed 5-7 branches or everything will just clutter up.

       Try to stand up when exercising your imagination. It will get stimulated more than in a constrained sitting position.

 

For more detailed information, go to the article below:

 

Reference
Reference
generalart
Mindmaps: see the content of your mind

 

3)     Think of behaviours, not implementation

If we are entirely new to TDD, we will get stuck for sure during that first cycle. Having that prominent feature we are faced with, we are determined to code it the TDD way. Finally, we have the guts to try this method out and are there in blocks with nothing on the horizon that would make us move forward.

The first tip I can give you is to think of behaviours. Small behaviours. Nothing flashy. BDD rules are perfect here. Known mostly from acceptance testing language, BDD is an excellent fit in any scenario.

Let's say we got that dream gig at a game-making studio. The task we are given is to write an engine for a castle siege. There is a myriad of actions that might be triggered in that complex process, but if we go deep down straight to the battlefield, we could think of this scenario: what happens when players hero dies? Do not wait for any second longer. Write a test now!

 

Test Code


@Test
public void shouldNotDieJustLikeThat_whenBeingCriticallyHit() throws Exception{
	// Given
	Hero hero = new Hero();
	Enemy enemy = new Enemy();
	Hit hit = new Hit();
	hit.setCritical(true);

	// When
	assertThrownBy(() -> enemyController.hitHero(hero, enemy, hit))
		// Then
		.isInstanceOf(HeroOvercomesDeathAndCrushesHisEnemy e);
}

Most likely, you would need to justify why such a thing should happen but do not limit your imagination right now! You have just written your first test in the test first way. Keep on throwing wood into the fire and keep that imagination rolling.

 

Tip
Tip

 

4) Test names first, implementation later

Sometimes you do not have a problem with the name of a test itself. What is troubling you is the actual content. How should you name the actual classes, what fields they should have? What combination of these would help me achieve the story described in the test name?

If you feel like you have a lot of stories in your head but having trouble in detailing them, do not worry. Leave the unit test implementation for later and just go with the flow. Write as many stories as possible.

This is called going for breadth, instead of depth for a particular feature. Having that castle siege in mind, we could let loose as follows:

 

Test Code


@Test
public void shouldLevelUpWithoutBonusSpell_whenGainingLevel10()

@Test
public void shouldIncreaseLevelByOne_whenGainingLevel()

@Test
public void shouldKillEnemyInstantly_whenStabbing_givenSubsequentCriticalHits()

@Test
public void shouldSplitEvently_whenDividingLoot_givenCastleTaken()

 

Tip
Tip

 

5) Integration Testing and TDD

Finally, if we cannot get going either for depth or for breadth on a unit testing level, have no fear, there is still a way. Do not drop TDD just yet! We will try to get some perspective by going for breadth but on a much higher level. That is the IT level.

You might ask: but TDD is strictly dealing with unit tests, we do not care about integration just yet. You are wrong. We are still in line with TDD spirit. We are starting with a test that will fail. The difference is just that it will keep failing for a bit longer than a unit test. That is fine! It is there to guide the more detailed TDD cycles in a specific direction. Exactly what we need in our case.

Let's try to write a bunch of more complex scenarios that might happen during our castle siege:

 

Test Code


@Test
public void shouldStealDefencePlans_whenBreakingIntoTheCastle_givenPlayingThief()

@Test
public void shouldDefendCastle_givenWeakAttacker();

@Test
public void shouldSuccessfullyEvacuateCastle_givenVeryStrongAttacker();

@Test
public void shouldDecreaseArmyMorale_whenBestWarriorDies();

Now having these in place. It should be easier for us to come up with unit tests that eventually would present the IT scenario in fine-grained detail.

 

Tip
Tip

 

 

6)     Conclusion

 

Summary

 

 

Do not get tangled up in your head that much. Get to the board, start mind-mapping, and one of the above strategies will unfold in front of you. Sometimes it is just about grabbing whatever you have at hand and going for that treasure and seeing what happens. That is why TDD is probably the coolest thing you can do at your boring everyday open-space desk.

 

Need more insight?
Repository
Repository
Glossary
Glossary
Tags:
Reference
You may also like:
tdd-refactoring-phase
TDD refactoring phase
tdd-common-mistakes
TDD Common Mistakes
Comments
Be the first to comment.
Leave a comment