Building is progressing at a good pace. Learning about testing in Django has definitely been more of a “RTFM” (Read the fudging manual) affair. However, I did find a good starting guide on Obey the Testing Goat. I just used it as a launching pad to get familiar with how testing is done in Python, and referred to Django’s documentation when needed. By the way, props to the team that wrote it. I would say that having robust documentation is at least as important as robust functionality.
At this point, I’m only utilizing two kinds of tests: functional, and unit. I’ll talk about both of these using an automobile analogy. Also, for more advanced developers reading this, please comment below if I’m inaccurate about something. I’m figuring this out as I go along, and would appreciate the feedback.
Functional tests are in reference to how a user interacts with the software. So using the car analogy, functional tests assert “the pedal on the right makes it go forward,” etc. How this manifests in web apps is “user expects title to be __,” “user expects this link to take us to this address.”
Unit tests cover the mechanics of how the app operates. With a car, this is akin to asserting “the airbag should deploy in x-number of miliseconds,” “the O2 sensor should have a refresh rate of __ Hz” (I have no idea if O2 sensors have a refresh rate, but anyway…), and none of these should be in a user’s thought process of using the car.
To me, it makes sense to write tests with a level of detail that’s proportional to the interaction(s) being tested. So it follows that a functional test should be less complex than the unit tests. As I started this, I found myself writing assertions for the same thing in both tests, so I had to pause & ask if it’s an expectation a user would have.
When writing software, every piece of it should only do one thing, and do it well. The same should be true for the code that’s testing it.
Here is a link to the project on Github if you want to follow along.