Github Repository

https://github.com/kcsuraj/task-management.git

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

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.

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

Automated GUI

tests

Integration

tests

Unit

tests

TDD Approach

UI

Integration

tests

Unit

tests