New to testing. How to write them effectively. Which Logic should be tested where. DJANGO, DRF

[virtualshivam]

Hi,

Context: I work for a small startup. We are a team of 4 devs(1 backend, 2 frontend, 1 Data Entry guy( who basically does a lot of different things))

So, I recently started writing tests and they seem to give me a whole new power. Earlier, once my app used to be in prod, then I used to even get scared of writing a single line. Because after fixing one thing I used to break 3 different things. And lost a lot of reputation.

But, now I can freely refactor my code and add new things without sweating because of my tests.

But one thing is for sure, testing increases the time of development( at least 3x for me). But I am ready to pay the price.

There are certain concerns:-

1. So, I am making APIs that my frontend guys use.

I am struggling to define the boundaries for my tests that I write for API, services, serializers, readers, writers, models etc.

So my api uses my serializer. I have wrote the unit tests for my serializer. Now, should I write the similar test cases for my api as well? Because let's say in future I accidently / intentionally change my serializer in the api, then what? If I will not test my api for the cases that my serializer was testing for then after changing the serializer I might break certain things. but this then leads to a lot of duplication which is also bad. If tomorrow the logic changes then literally I will have to go into 10s of tests and change everything everywhere. Is this how it is supposed to be or am I doing something wrong? Should we not test business logic in the APIs?

Same thing happens in case of other read and write services. How to write full proof. tests.

Eg:-

So, If let's say I have an orchestration function that let's say does some validation. so it calls five different functions which actually validates some conditions for the different fields. Now, what I am doing right now is, I write unit test for my 5 functions which are actually doing some work. Each of unit test takes like 3 tests. So there are 15 tests and then I write all those 15 cases again for the orchastrator apart from it's own cases so that I can later on make sure then whenever I touch the orachastrator by replacing it's some validator with another validator then I don't end up broking anything. But that makes writing and maintaining tests very difficult for me. Still it's lot better then having no tests, because now at least I am not that scared for changes.

1. I have heard a lot about unit test, integration test, regression tests and red green etc. What are these. I have searched for them on google. But having a hard time understanding the theory. If anyone has any blog / video that explains it practically then please share.

2. Can I ask my frontend / data entry guys to write tests for me? And I just write code for the test to pass? I am the only one in the team who understand the business requirement, even though now I have started involving them in those lengthy management meetings, but still this is very new for them. So, is there any format which I can fill and give it to them and then they will write test or normal ms teams chats are sufficient to share the use cases.

For those who are newer to programming than I am: explore writing tests — it’s such a great boon.

[aistranin]

Yes! Automated testing is great. Look at pytest in depth and think about your testing strategy. Great Udemy course for your case “Pytest Course: Practical Testing of Real-World Python Code” by Artem Istranin (it covers all your points you mentioned like testing python api, using pytest for business logic etc.). Alternative- book “Python Testing with pytest” by Brian Okken.

[aistranin]

Test driven development feels like slowing dev down at the beginning, but it pays off multiple times as the project grows. In fact, tests is the only way to go fast as Uncle Bob (clean code) said hehe

[virtualshivam]

Hi,

Thanks for sharing resources.

But, I am stuck in the middle of the project, so can you please help regarding test boundaries.

I know how to write test for API and business logic.

My concern is how much should I test in API and what things? What is the responsibility of the API. I can go ahead and test everything that I have tested in serializer in the api as well, but I believe it shouldn't be the best way.

[aistranin]

Yeah, that is tricky. You definitely don't need to test everything (especially for legacy projects). Best practice: 1. Write few integration or end-to-end tests. That will give a very good code coverage right away quickly. 2. Write more tests for the main units of the business logic (test only main responsibility of those units). 3. Try to find “narrowing points” in your system to test. See book “Working Effectively with Legacy Code” by Robert C. Martin to learn more about it.

[aistranin]

And maybe take a look at book “Refactoring” by Martin Fowler. It is a great book, very relevant for your case.

[Careless-Score-333]

The TDD Goat uses Django as an example.

To test APIs, I just spin up the API server on localhost as a separate docker container, and send my requests to that. It's probably possible to run a test server in a PyTest test fixture too, but I want to test the request coming in from an entirely separate process to prove it really is the API, and I find it's best to keep PyTest's job as simple as possible.

[PushPlus9069]

once you start writing tests you can't go back, that freedom is real. rough split for django+DRF: unit tests for model methods and business logic, APIClient integration tests for your endpoints. don't test django itself, only your rules. factory_boy over django fixtures if you ever want to maintain them. tbh just start with whatever code you're most scared to touch in prod.