On testing, I think "one file & class per thing-to-test" is subtly bad advice. It's not harmful in the hands of someone that knows what they are doing, but it tends to point engineers towards a tightly-coupled test suite, which ends up making refactoring more painful and error prone down the road.
If you have one testclass per entity, then if you make any changes to the structure of your services/models/entities, you must restructure your tests too. This means you can't do the "dream refactor" where you don't touch your tests, and restructure your code without changing any behavior. If you rewrite your tests whenever your structure changes, how can you be sure you've not broken your tests?
Instead, I advocate for testing behaviors. In a tightly-integrated framework like Django, most of your tests are going to be integration tests (i.e. you have a database involved). You should bias those tests towards an integration-y approach that uses the public interfaces (Service Layer, if you have one) and asserts behavior. Ideally the tests should not change if the business logic has not changed. (In practice you'll often need to add some mapping/helper/setup code to make this true.)
If you have any fat-model type behavior that is explicitly scoped to a single model, then you can test that in isolation. Many Django projects call these "unit tests" even though they still involve reading and writing your model from the DB. I call them "focused integration tests". All that matters is that you have agreement on terminology inside your project. If you have extremely complex domain logic, it can be worthwhile to construct "true Unit Tests" that use dummy objects to test logic without hitting your DB. I've not found it worthwhile to mock the DB in most Django projects though.
To provide an example of where my "test behaviors not classes" advice differs from the OP's paradigm, let's say you split out a sub-object to provide a pluggable Strategy for a part of your Model's behavior -- you don't necessarily need to have detailed tests for that Strategy class if it's fully covered by the model's tests. Only the edge cases that are awkward to test at the higher level need to be tested at the granular level of the Strategy. Indeed, the first refactor that just creates a Strategy holding your existing behavior need not change any of your existing tests at all! Indeed, if you do need to change existing tests, that suggests your tests were improperly-coupled to the code under test, since a mere structural change like this should not affect the behavior of your application. Even after adding more Strategy logic, most of your old ModelTests are still good; they still test the high-level behavior, and now also test the integration between your model and the new Strategy class. Basically, test at the most-granular level that gives a clear, decoupled test for your behavior; resist testing every entity in isolation, because some entities have rich coreographies with other entites that make them hard to isolate. Sometimes you have to contort and tightly-couple in order to test things at the very-lowest-level possible.
Inspiration/further reading: https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrav.... (Grit your teeth through the "Socratic dialog" style. The principle being described is extremely valuable.)