Test Driven Development - Notes
Tags: testing
Published: 2021-10-09 02:46:10

- 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
```java
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](https://stackoverflow.com/questions/1077412/what-is-an-idempotent-operation)
- [Side effects](https://softwareengineering.stackexchange.com/questions/40297/what-is-a-side-effect)
- 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