Notes - Test Driven Development

• 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
• 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.