It sounds like you were doing two things that don't really work well in Python + framework environments in my experience: 1. Depending on internal state: I've

It sounds like you were doing two things that don't really work well in Python + framework environments in my experience: 1. Depending on internal state: I've always had a harder time working with state, regardless of language. I usually try to structure my code so that most of my business logic is encoded in functions that have inputs and outputs and don't modify any state. Only the toplevel functions modify the state, and they do so by applying database queries or updates that were generated functionally. This also can often drastically simplify or even eliminate your mocks. 2. Not unit testing. Without static types, it's pretty necessary to unit test. Think of it as that you test whether the types are correct by trying to use them in a trivial case. This is a double edged sword: on the one hand, unit tests give you more than static types: a type checker can tell you if the two things you're adding aren't numbers, but it can't tell you that you're adding the wrong numbers. The flipside is that nothing will tell you if you didn't test something, or didn't test it correctly. I don't know if you'll have opportunity to try it again, but maybe next time try a test-driven development (TDD) approach where you define your function's interface (inputs and outputs) write failing tests that test those inputs and outputs, and then implement to make those tests pass. I don't encourage dogmatic TDD, but it can be a good starting point. Once you get a good feel for what kinds of interfaces are testable and where tests are helpful, you can scale back your testing a bit and test more pragmatically as needed.