Building a Productive Software Team in the First 90 Days - a 5 Step Guide for CTOs
As a newly appointed CTO or Engineering Leader, the first 90 days in the role, company or project is a critical time; get it right in this quarter..
We begin this journey through the simplest TDD katas. Below, you will find a list of them along with a link that will take you to a detailed explanation of each one and the solved exercise.
In each link of every kata, you'll find an introduction that will help you get context, followed by the details you need to execute it. And remember: the best way to learn and improve is by practicing. Shall we begin?
FizzBuzz: This kata involves conditionals, parameterization of different cases, and it is recommended to take baby steps to reinforce the importance of "fake it until you make it" and ensure that tests fail only for the right reason. One of the recommendations we usually make is that while doing the kata:
Iteration 1: TDD cycle + Baby steps
Iteration 2: Work on the TPP (Transformation Priority Premise)
Iteration 3: If a test fails, revert changes (Test commit or revert)
Leap year: This kata presents a slightly more complex algorithm, perfect for working with nested conditionals.
Iteration 1: TDD cycle + Baby steps
Mastermind: Simple algorithm kata, where
Iteration 1: Fake it until you make it, TDD Cycle, baby steps
Iteration 2: Fake it until you make it, TDD Cycle, baby steps, parameterization of tests, clean code
Iteration 3: The above + OOP
Iteration 1: Fake it until you make it, TDD Cycle, baby steps
Iteration 2: Fake it until you make it, TDD Cycle, baby steps, parameterization of tests, clean code
Iteration 3: The above + OOP
Could you make the code chosen by the codemaker generated by the game?
How would your design change?
What tests would you miss?
Rock Paper Scissors Kata: It works with conditionals, parameterization, and the business specifications are similar to these, introduction to the first key-value data structure.
Iteration 1: TDD cycle + Baby steps
Iteration 2: Parameterization
Iteration 3: No else statement
String Calculator: The goal of the kata is to use incremental iterative work, with conditionals and parameterized tests.
Iteration 1: TDD cycle + Baby steps
Iteration 2: Work on the TPP
Iteration 3: If a test fails, revert changes (Test commit or revert)
Roman Numeral: Reinforcement of the concept of loops and basic key-value data structures. A very illustrative kata of what the Transformation Priority Premise (TPP) is. Iteration 1: TDD cycle + Baby steps + Parameterization
Iteration 2: Work on the TPP
Iteration 3: If a test fails, revert changes (Test commit or revert)
When you finish the kata, ask yourself the following question: How complicated would it be to add a new number?
Build a Christmas tree: This kata works on basic algorithmics, teaches how to test the output, and encapsulate concepts.
Iteration 1: TDD cycle + Baby steps + Learn to test the output with a specific format Iteration 2: Adapt your code so that, given the size of the tree, you can create one of any size. (Learn about Fixtures)
Employee Report: Kata to start learning about loops and/or higher-order functions, as well as working on making good assertions.
Code Syntax: Works on algorithmics, data structures, or state machines.
Bowling: Kata designed to practice TPP.
Stack: With the introduction of Objects, this kata poses the challenge of constantly thinking about possible modifications to this object, making us aware that it is an object open to modifications. Therefore, our tests should not be coupled to the implementation of this object. It is mandatory to use baby steps and the TPP so that one of our tests is not testing too many things at once or that our tests know too much about the implementation.
Iteration 1: TDD cycle + Baby steps (important: tests must be deterministic and fail only for one reason)
Iteration 2: If a test fails, revert changes (Test commit or revert)
Learn about the difference between a "public" and a "published" API; it is important to understand when we are testing a library that must have an open API/Interface/Contract so that it can solve unknown problems, versus implementing a business functionality that solves one clear problem, and the API/Interface/Contract can be more closed, as we know exactly the use that will be given to our code.
Simple Mars Rover: More complex algorithm with data structures and introduction to basic command and query (in terms of concepts), introduction to state in the application.
Iteration 1: Structured
Iteration 2: OOP
Iteration 3: Introduce at the end of your kata and only after finishing, the possibility that your kata can move in 45 degrees, i.e., N, NE, E, SE, S, SW, W, NW
Iteration 1: Structured
Iteration 2: OOP
Iteration 3: Introduce at the end of your kata and only after finishing, the possibility that your kata can move in 45 degrees, i.e., N, NE, E, SE, S, SW, W, NW
Potter kata: Interesting algorithmic kata where the focus is on assertions and incremental iterative development:
Iteration 1: Baby steps
Iteration 2: Use mutant testing on your previous kata, see how many mutants survive and how to improve your tests
Iteration 3: Application of object calisthenics
Iteration 1: Baby steps
Iteration 2: Use mutant testing on your previous kata, see how many mutants survive and how to improve your tests
Iteration 3: Application of object calisthenics
