4 ms·

I wasn't, but I guess this is the only solution. The biggest reason I didn't unit test was that most of my functions were dependent on a significant amount of i

I wasn't, but I guess this is the only solution. The biggest reason I didn't unit test was that most of my functions were dependent on a significant amount of internal state. I suppose I should have spent more time coming up with mock models to use during unit tests. Also separating functionality would have made things easier.

gedrap 10y ago
This sounds more like an issue with the application design rather than Flask, Python, or even Web development. How easy or hard it is to test software is often a good indicator of the quality of the underlying design - if it is too hard to separate code into testable units and you have to mock loads of things to test for the most basic cases, there's a more fundamental problem somewhere. Of course, there are things that are hard to test, but it shouldn't be the whole application that is hard to test.
kerkeslager 10y ago
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.

gedrap 10y ago

This sounds more like an issue with the application design rather than Flask, Python, or even Web development. How easy or hard it is to test software is often a good indicator of the quality of the underlying design - if it is too hard to separate code into testable units and you have to mock loads of things to test for the most basic cases, there's a more fundamental problem somewhere. Of course, there are things that are hard to test, but it shouldn't be the whole application that is hard to test.

kerkeslager 10y ago

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.