Please enable JavaScript.

Coggle requires JavaScript to display documents.

Test Driven Development (two types of test, the high-levelfunctional tests…

- - - - • Start by writing a unit test which fails (Red).
        
        • Write the simplest possible code to get it to pass (Green), even if that means cheating.
        
        if your tests let you get away with writing “cheating” code that you’re not happy with, like returning a magic constant, write another test that forces you to write some better code
        
        • Refactor to get to better code that makes more sense.
- - - - One of the reasons that the “three strikes and refactor” rule exists is that, if you wait until you have three use cases, each might be slightly different, and it gives you a better view for what the common functionality is. If you refactor too early, you may find that the third use case doesn’t quite fit with your refactored code…
  - - - Our natural urge is often to dive in and fix everything at once…but if we’re not careful, we’ll end up like Refactoring Cat, in a situation with loads of changes to our code and nothing working. The Testing Goat encourages us to take one step at a time, and go from working state to working state.
    - - You ain’t gonna need it! Avoid the temptation to write code that you think might be useful, just because it suggests itself at the time. Chances are, you won’t use it, or you won’t have anticipated your future requirements correctly. See Chapter 22for one methodology that helps us avoid this trap.
    - - Try to write the minimal tests that will give you confidence that your design and layout is working, without testing what it actually is. Aim to leave yourself in a positionwhere you can freely make changes to the design and layout, without having to go back and adjust tests all the time.
      - The short answer is: you shouldn’t write tests for design and layout per se. It’s too much like testing a constant, and the tests you write are often brittle.
    - - Just as you use multiple files to hold your application code, you should split your tests out into multiple files.
        
        • For functional tests, group them into tests for a particular feature or user story.
        
        • For unit tests, use a folder called tests, with a init.py.
        
        • You probably want a separate test file for each tested source code file. For Django, that’s typically test_models.py, test_views.py, and test_forms.py.
        
        • Have at least a placeholder test for every function and class.