Notes - Test Driven Development

Published on

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