Test Driven Development (TDD)
Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.
Without properly testing your code, you will never know if the code works as it should, now or in the future when the code-base changes. Countless hours can be lost fixing problems caused by changes to the code-base. What’s worse, you may not even know that there are problems at all until your end users complain about it, which is obviously not how you want to find out about code breaks.
Having tests in place will help ensure that if a specific function breaks you will know about it. Tests also make debugging breaks in code much easier, which saves time and money.
I’ve literally lost gigs in the past from not properly testing new features against the old code-base. Do not let this happen to you. Take testing seriously. You will have more confidence in your code, and your employer will have more confidence in you. It’s essentially an insurance policy.
Testing helps you structure good code, find bugs, and write documentation.
Unit and integration are the two main types of tests:
Unit Tests are isolated tests that test one specific function.
Integration Tests, meanwhile, are larger tests that focus on user behavior and testing entire applications. Put another way, integration testing combines different pieces of code functionality to make sure they behave correctly.
In general, tests result in either a Success (expected results), Failure (unexpected results), or an error. You not only need to test for expected results, but also how well your code handles unexpected results. Best practices
1. If it can break, it should be tested. This includes models, views, forms, templates, validators, and so forth.
2. Each test should generally only test one function.
3. Keep it simple. You do not want to have to write tests on top of other tests.
4. Run tests whenever code is PULLed or PUSHed from the repo and in the staging environment before PUSHing to production.
5. When upgrading to a newer version of Django:
* upgrade locally,
* run your test suite,
* fix bugs,
* PUSH to the repo and staging, and then
* test again in staging before shipping the code.
Structure your tests to fit your Project. I tend to favor putting all tests for each app in the tests.py file and grouping tests by what I’m testing - e.g., models, views, forms, etc.
You can also bypass (delete) the tests.py file altogether and structure your tests in this manner within each app:
└── app_name
└── tests
├── __init__.py
├── test_forms.py
├── test_models.py
└── test_views.py
Finally, you could create a separate test folder, which mirrors the entire Project structure, placing a tests.py file in each app folder.
Larger projects should use one of the latter structures. If you know your smaller project will eventually scale into something much larger, it’s best to use one of the two latter structures as well. I favor the first and the third structures, since I find it easier to design tests for each app when they are all viewable in one script.