/100-doors-tdd-kata-typescript

100 doors tdd kata from test buddy.com in typescript

Primary LanguageTypeScript

tdd-fundamentals-in-typescript

100 doores TDD Kata Link :

https://www.tddbuddy.com/katas/100-doors.html

Config :

  1. Set up the node project

     npm init -y

  2. Install typescript / jest / types for jest / typescript jest translator . As dev dependency's

       npm i -D jest typescript @types/jest ts-jest

  3. Set up the jest config file :

       npx ts-jest config:init

    Which will create jest.config.js file

  4. Create a .tsconfig.json file with the following command ( to get rid of the error message in the command line while running jest):

     npx tsc --init

  5. Next set up a script to run tests every time there is a change in the code :

        "scripts": {
      "test": "jest --watchAll --verbose"
    }

  6. Copying the Starter TDD configuration for any project

    1. create a new project :  mkdir new-tdd-node-project 
    2. move all configuration , except node_modules to new   project:   mv  ../tdd2/*.* ./    
    3. install all node dependencies :  npm i 
    4. run the jest script :  npm run test

Typical Structure of a Test

  1. Arrange : Get together all the variables needed to conduct the test .
  2. Act : Execute the 1 thing to be tested.
  3. Assert : Verify your actual value matches the expected value.

Test

F.I.R.S.T Principles for Testing

The principles you should keep in mind while writing any test code

  1. (F)ast : The test should be FAST
  2. (I)ndependent/Isolated : The test should be independent and self contained ( our test should not depend on external dependencies , and one test should not interfere with other tests , and does not depend on external databases / http requests etc )
  3. (R)epeatable : Every time the test is executed , the result should be the same [ Deterministic test ]
    • Should not have flickering tests i.e: Some times pass / other times fail
  4. (S)elf-Validating : Tests should either pass or fail
  5. (T)horough : Tests should cover all scenarios at the unit level using TDD. Because , as you go up , the tests become less.
    • E2E tests are the least ( as they take a lot of time)
    • Integration Tests are a bit more (As they take a little less time )
    • Unit tests are the most (As they take the least time and can cover all scenarios at the unit level) .

The 3 Laws of TDD

  1. You are not allowed to write any production code unless it is to make a production code pass
  2. You are not allowed to write any more of a unit test than is sufficient to fail ; a compilation error is a failure
  3. You are not allowed to write any production code than is sufficient to pass the one failing unit test