# Chapter 2. Extending Our Functional Test Using the unittest Module

We are trying to build to-do list Django web app

## 2.1 Using a FT to Scope Out a Minimum Viable App

* **Functional Tests** = tests that let us see how the app *functions* from user's perspective
  * It's like a specification for app
  * Tends to track *User Story*
  * **Functional Test** == **Acceptance Test** == **End-to-End Test**

Steps to create a FT for a MVP/A:

1. Prepare a User Story (e.g. user story for to-do list)
2. Add test assertions along user story, which is *expected fail*

## 2.2 Python Standard Library's unittest Module

python's default `assert` isn't helpful. 

> The assert keyword is used when debugging code.
> The assert keyword lets you test if a condition in your code returns True, if not, the program will raise an AssertionError.

`unittest` module of python standard library can be used

* tests can be organized into classes, which inherit from `unittest.TestCase`
* `setUp` and `tearDown` are special methods that will be run before/after each test, even test failed
* main body of tests is in `test_can_start_a_list_and_retrieve_it_later`. 
* **Any method whose name starts with test is a test method, and will be run by test runner**
  * Can have more than one test methods per class.
* Use `self.assertIn()` instead of `assert`. More helper functions like `assertEqual`, `assertTrue`, and `assertFalse` are available in *unittest*
* `warning='ignore'` suppresses a superfluous `ResourceWarning`.

Hence, a full cycle of test can be executed as it 

1. Open Firefox
2. Test title
3. Close Firefox
4. Return test result

## Useful TDD Concepts in this chapter

* **User Story**: A description of how the application will work from the point of view of the user. Used to structure a functional test.
* **Expected Failure**: When a test fails in the way that we expected it to.