Test Driven Development

Testing

  1. a set of problems, questions, etc., for evaluating a person's abilities, skills, or performance

  2. the means by which the quality of anything is determined

  3. a trial of the quality of something

To test a software means to check if the software is doing what needs to be done

Automated Tests

An automated test is a software that tests your software

Test Types

(what)

Unit tests

Integration tests

end-to-end (aka e2e) tests

Test Types

(how)

Regression tests

Smoke tests

Black-box testing

White-box testing

Monkey testing

Costs

Test Automation Pyramid

Documentation

xUnit architecture

Kent Back created 'SUnit' for SmallTalk. From that first implementation a more generic architecture it's born

Test Runner

Test Case

Test fixtures

Test Suite

Assertions

Test result formatter

Mocking

  1. to make fun of

  2. to imitate or mimic

  1. to make fun of

  2. to imitate or mimic

mocking is creating objects that simulate the behaviour of real objects.

Test Driven Development

Test Driven Development

Kent Beck has developed this technique and distilled it in his famous book "Test Driven Development: By Example" in 2003

Create a test case before start writing the code

Write the simplest code possible to pass that test

Iterate

Refactoring after each iteration

When you pick the next test try to write a test that will teach you something new

I really mean the simplest code ever possible...

describe('inner', () => {
  it('should add correctly', () => {
    expect(add(2,2)).toBe(4)
  });
});
const add = (a,b) => {
    return 4;
};

During the Refactoring phase you can also delete unuseful tests

Why?

Better Design

A testable code it's probably cleaner that an untestable one 

Dependency Injection

Less Regressions

All of your important code it's tested

Customer centric code

Testing before writing force you to write only the code that you really need

You focus on 'what' and not on 'how' 

YAGNI

You Aint Gonna Need It

Costs

ShuHaRi

ShuHaRi roughly translates to "first learn, then detach, and finally transcend."

Shu =  "protect", "obey"

Ha = "detach", "digress"

Ri = "leave", "separate"

Rules --> Principles --> Innovation

Bonus: User Stories

A User Story it's a way to represent requirements

As a <role>, I want <goal> so that <benefit>

Every User Story should have an acceptance test to understand when the story it's completed

With TDD you switch the focus on 'What'. With User Stories you focus on 'Why'

Acceptance Test Driven Development (ATDD)

In The End the purpose of the user stories it's to discuss details at The Last Responsible Moment

Useful links

That's It!

Thanks!

TDD

By extrategy

TDD

  • 1,974