Test Driven Development - Notes

#testing

The art of a good night's sleep is knowing you will not get woken by a support call and the piece of mind from being able to confidently change your software in an always moving market. - Nic Jackson
change in code can have undesirable effect on the other parts, tests helps in making the process of changing code in future easy
testing pyramid: unit testing(bottom), service/integration(middle), ui/end-end(top)
- test cases should decrease as you go from bottom to top
Approach
Just write test first (use expected function)
Run and fail the test
Write minimal code for the test to run and fail
Write minimal code to make test pass
Test same function with different values
Make sure all tests are passing
Tests for base cases
Refactor both code and tests

Features and scenarios

Given a feature, break it down to scenarios. Each feature is a user story
- Example Feature: As a user when I call the search endpoint, I would like to receive a list of kittens
- Break it down to scenarios
  - 1st Scenario: Invalid query Given I have no search criteria When I call the search endpoint Then I should receive a bad request message
  - and so... on number of different scenarios

Uncle bobs, rules of unit tests

First law: You may not write production code until you have written a failing unit test
Second law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing
Third law: You may not write more production code than is sufficient to pass the currently failing test

Naming

my convention: TestNameReturnSomethingWhenSomethingHappens
- example: TestDogHandlerReturnsBadRequestWhenNoSearchCriteriaIsSent

AAA format for testing - Arrange, Act, Assert

I always try to follow this pattern for clean code

public class CalculatorTest{
    public void sumOfTwoNumbers(){
        //Arrange
        double first = 10;
        double second = 20;
        var Calc = new Calculator();

        //Act
        double result = Calc.Sum(first, second);

        //Assert
        Assert.Equal(30, result);
    }
}

concepts

Idempotency
Side effects
A stub is a fake class that comes with preprogrammed return values. It’s injected into the class under test to give you absolute control over what’s being tested as input. A typical stub is a database connection that allows you to mimic any scenario without having a real database.
A mock is a fake class that can be examined after the test is finished for its interactions with the class under test. For example, you can ask it whether a method was called or how many times it was called. Typical mocks are classes with side effects that need to be examined, e.g. a class that sends emails or sends data to another external service.
Learn mocking - https://semaphoreci.com/community/tutorials/stubbing-and-mocking-with-mockito-2-and-junit
Wrapper: something which hides implementation of some other code or internally uses other code.

visit my personal blog: https://rahilrehan.github.io