# Clean Code - 9 Unit Tests
Writing automated unit tests is encouraged because of the trend of Agile and TDD movements. However, it is important to **write good tests instead of just writing tests**.

## The Three Laws of TDD
Other resources:
https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
https://www.ibm.com/garage/method/practices/code/practice_test_driven_development/

> The tests and the production code are written together, with the tests just a few seconds ahead of the production code.
>
>
> ### 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.

#### Example
**Phase 1**
Write a first failing unit test:

// production codes
// first method
function getNumbersFromStringKey(sourceStr: string) : number {
    
}

// below are unit tests
function testGetNumbersFromStringKeyWithNumberStr() : void {
    const result = getNumbersFromStringKey('010789666');
    expect(!Number.isNaN(result)).toEqual(true);    
}

**Phase 2**
Since the unit test `testGetNumbersFromStringKeyWithSpaces` will fail, should modify the production codes to pass the test case, instead of creating more test cases:

// production codes
// first method
function getNumbersFromStringKey(sourceStr: string) : number {   
    return +sourceStr;
}

// below are unit tests
function testGetNumbersFromStringKeyWithNumberStr() : void {
    const result = getNumbersFromStringKey('010789666');
    expect( !Number.isNaN(result) ).toEqual(true);    
}

function testGetNumbersFromStringKeyWithSpaces() : void {
    const result = getNumbersFromStringKey('010 789  666');
    expect( !Number.isNaN(result) ).toEqual(true);    
}

**Phase 3**
Can start to write another production method after all unit tests pass:

// production codes
// first method
function getNumbersFromStringKey(sourceStr: string) : number {   
    const result = +sourceStr.replace(/\D/g, "");
    return result;
}

// below are unit tests
function testGetNumbersFromStringKeyWithNumberStr() : void {
    const result = getNumbersFromStringKey('010789666');
    expect( !Number.isNaN(result) ).toEqual(true);    
}

function testGetNumbersFromStringKeyWithSpaces() : void {
    const result = getNumbersFromStringKey('010 789  666');
    expect( !Number.isNaN(result) ).toEqual(true);    
}


function testGetNumbersFromStringKeyWithNotNumber() : void {
    const result = getNumbersFromStringKey('010*789++666');
    expect( !Number.isNaN(result) ).toEqual(true);    
}

## Keeping Tests Clean
When tests are dirty, it's almost the same as no tests. Discipline is:
> Test code is just as important as production code.

#### How dirty tests affect production codes
- Scenario 1: When updating the function body of the production codes (still the same API, only change the body of a function)
- The dirty tests will not fail since the goal of functions does not change
- Scenario 2: When updating the entire API (for example, new functions take more parameters, or some functions no longer exist)
- The dirty tests will fail and it takes lots of effort to fix them to pass the new functions


### Tests Enable the -ilities
Keeping unit tests clean helps keep production code flexible and makes changing it easier and more confident.

## Clean Tests
The clean test is all about readability. Readability includes:
- Clarity
- Simplicity
- Density of expression: eg, if, while, should not have too many, should not be too complicated

#### Bad unit tests example in Jave

#### Same unit test after refactor
Use the BUILD-OPERATE-CHECK pattern
http://fitnesse.org/FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.AcceptanceTestPatterns.BuildOperateCheck


### Domain-Specific Testing Language
Write your own API for test use, and you need to constantly update and refactor according to test needs.

#### Example
**Before having APIs:**

**After writing and using the APIs:**


### A Dual Standard
While APIs for testing needs to be as simple and clean as production code, they **don't need to be as efficient as production code**. The reason is that the tests are run in a test environment, which has different requirements than the production environment.

#### Example
**Need to move eyes back and forth to read the test:**

**Increase the readability:**

**How the `getState` method is implemented:**

## One Assert per Test
Sometimes the **same code can appear in multiple tests** when there is only one assert in each test:


#### Template Method
To solve the above duplication of code problem, can use the Template Method.
Source https://www.artima.com/weblogs/viewpost.jsp?thread=35578

Use **Given, When, Then**:
- Given
- preconditions, things should be done **before tests**, and be written as a function
- When
- actions
- Then
- verification

Example in pseudocodes:

Scenario: test sign-in user checkout
    Given: create an account and sign in
    When: put a product in the cart and checkout
    Then: the order summary has the user and product information

### Single Concept per Test
Test a single concept in each test function. When there are multiple concepts in a test:


**The scenarios and preconditions in the above test:**
> Given the last day of a month with 31 days (like May):

**Scenario 1:**
Add 1 month, the last day of the new month should be 30th
**Scenario 2:**
Add 2 months, the last day of the new month should be 31st

> Given the last day of a month with 30 days in it (like June):

**Scenario 3:**
Add 1 month, the last day of the new month should be 30th

The above test should be divided into 3 tests. Should also include other missing tests like **the last day of a month with 28 days in it (like February)**

## F.I.R.S.T

### Fast
> Tests should be fast. They should run quickly.

### Independent
> Tests should not depend on each other.

### Repeatable
> Tests should be repeatable in any environment.

For example, tests should be able to run on both the production environment and the OA environment.

### Self-Validating
> The tests should have a **boolean output**. Either they pass or fail.

### Timely
> The tests need to be written in a timely fashion. Unit tests should be written just **before** the production code that makes them pass.

## Conclusion
We should always keep our tests clean.

###### tags: `learn` `clean code` `test automation`