The document provides guidance on developing a testing styleguide for Django projects. It discusses what to test, including user-facing functionality ("what you like") and following Martin Fowler's Test Pyramid. It also discusses how to structure tests with recommendations like agreed folder structure, test naming conventions, and testing single behaviors rather than logic. It provides dos and don'ts such as using factories instead of fixtures, avoiding reliance on system time, and using verbose names and clear failure messages. It also discusses best practices for mocking and maintaining test coverage.

1. Joseph Victor Zammit
A minimal Django testing
styleguide
Django Day Copenhagen 2023
@jvzammit

2. What is it
that
troubles
us?

3. "Every task your organization
has to do repeatedly should be
scalable (linear or better) in terms
of human input.
Policies are a wonderful tool for
making process scalable."
[Software Engineering at Google]

4. Styleguide gains and tradeo
ff
s

5. What should our style guide be about?
1. What to test
2. How to write them tests

6. 1. What to test

7. The Beyoncé rule
If you like it put a test on it.

8. Martin Fowler’s Test Pyramid
martinfowler.com
Source:
[Software Engineering at Google]

9. Testing Trophy by Kent C. Dodds
@kentcdodds
Source:
[Software Engineering at Google]

11. 2. How to write tests

12. Thinking about the test (1)
“Errors are much more
common in the
neighbourhood of logical
conditions than they are in the
locus of sequential
processing statements.”
[Pressman]

13. Thinking about the test (2)

14. Thinking about the test (3)

15. Thinking about the test (4)
Equivalence partitioning is a black-box
testing method that divides the input
domain of a program into classes of data
from which test cases can be derived.
[Pressman]

16. DO’s and DONT’s

17. DO: agree on test folder structure

18. DO: agree on test structure
could be better
"When orders created today are retrieved"
hmmm
An alternative to
Given/When/Then
is
Arrange/Act/Assert

19. DO: test case and tests
naming conventions
and
DO: Use verbose test
function names

20. DO: a test should test only one behaviour

21. DON’T: put logic
in tests, and:
DON’T: try to DRY
Source:
grugbrain.dev

22. DO: follow
the LoB
principle

23. DON’T use
fi
xtures, instead DO use factories

24. DON’T use numbered variables
DON’T have tests relying on system clock

25. DO: Use clear failure messages

27. DO: Test behaviour not internal logic/state
}

28. DO use mock but DON’T over-mock
Agree on best practices when using unittest.mock
• Mock carefully
• Do not use mock to, for example:
• create request objects -> django.test.RequestFactory, DRF’s APIRequestFactory
• Otherwise "autospec"
• DO: Use a convention for where to apply mocks
• e.g. prefer class/function decorators to avoid with statement context manager
• DO: Use a convention for naming mocks
• e.g. mock_make_request vs p_make_request vs make_request
• Decide on packages like requests_mock, and apply uniformly throughout codebase

29. DO: play the game of test coverage
“Every work day we
increase our test coverage
is a victory, and every day
the coverage goes down
is a loss."
[Two Scoops of Django]
One rule: no commit can lower test coverage
• What is coverage?
• What should we cover?
• How to enforce in teams?
• non-negative di
ff
-coverage

31. Takeaways
- style guide
- what tests & how to write them

32. write tests you want to read
Code is read far more than it is written, so make sure you

33. Tak!
Thank you audience!
Thank you organisers!
Joseph Victor Zammit
@jvzammit