Title Text

Test Driven Development in JS

Background

  • Developers don't want to write tests 

    • They can't see the value of their effort

    • They just want to build softwares

    • Writing test cases is very time consuming

  • Project deadlines

  •  Project managers / leads don't see value of automated tests

  • Confusion on who should write tests - QA/developers ?

  • Everyone says tests are important but they do not want to commit time and energy in writing tests 

Types of Automated Testing

  • Unit testing: 

    • Each unit of our application, considered in isolation, is working correctly

  • Smoke test:

    • Check that the system is up and running.

  •  Integration test:

    • Verify that two or more modules can work well together

  • End-to-end test:  

    • Testing the application the same way it would be used in the real world

  • Acceptance test:

    • Done by the business owner to verify that the system meets specifications

  • Performance test:

    • See how the system performs under significant load

Introduction

  • Technique for building software that guides software development by writing tests

  • Tests are created before code is written

  • Tests specify and validate what the code will do

  • Developers write tests ( not testers ) then codes

Benefits

  • Mostly about design
  • Gives confidence
  • Is automated
  • Validates your design
  • Is documentation in itself
  • Provides rapid feedback
  • Requires more discipline
  • Brings professionalism to software development
  • Improves quality of implementation

Current Approach

Design

Code

Test

Test Driven Approach

Design

Test

Code

The principle

Red

Green

Refactor

Test Driven Process

  • Red: Write a little test that does not work and perhaps does not even compile first

  • Green: Make the test work quickly, committing whatever sins necessary in the process

  • Refactor (if needed): You should feel confident refactoring your code now that you have a test to tell you if you’ve broken something.

Make it green,

then make it clean.

3 laws of TDD

  • Law 1: You may not write production code unless you have written a failing unit test

  • Law 2: You may not write more of a unit that than is sufficient to fail

  • Law 3: You may not write more production code than is sufficient to make the failing unit test pass.

The zen of TDD

  • Avoid implementation details, test behaviors

  • A test case per class approach fails to capture the ethos for TDD.

  • Adding a new class is not the trigger for writing TDD tests.

Coupling is a bad practice

A test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can't run at the same time as other unit tests
  • You have to do special thins to your environment ( such as editing config files) to run it

Traditional Approach

Manual UI tests

Manual UI tests

Automated GUI

tests

Integration

tests

Unit

tests

Slower,

more expensive

Faster, cheaper

TDD Approach

Manual UI tests

UI

Integration

tests

Unit

tests

Slower,

more expensive

Faster, cheaper

Remember, you don't write tests for yourself! You write them for those who make changes later.

Test Driven Development in JavaScript

By surajkc