3 ms·

I've used some example architectures in the past while making a relatively small but very detail-oriented Flask app. I found that testing was a nightmare becaus

I've used some example architectures in the past while making a relatively small but very detail-oriented Flask app. I found that testing was a nightmare because my errors were only triggered on runtime. So I ended up having to manually test each code path in order to make sure I didn't have something as simple as a type error in my code. Static analysis helped a bit, but it's not as rigorous as a proper type system. Do you have any advice for this situation? It turned me off of web development in Python almost entirely.

gedrap 10y ago
What exactly do you mean by 'errors were only triggered on runtime'?
RussianCow 10y ago
I'm not sure I really understand what you're saying, but in any case, this is a problem with any dynamically typed language, and isn't in any way specific to Flask or even Python. If writing applications without the guarantees of a "proper type system" is painful for you, then Python is probably the wrong language. That said, you shouldn't have to manually test anything—that's what automated tests are for. With regard to testing Flask applications specifically, there is a guide[0] in the docs that covers everything you need to get started. [0]: http://flask.pocoo.org/docs/0.11/testing/ http://flask.pocoo.org/docs/0.11/testing/
kerkeslager 10y ago
Are you unit testing?
- doomrobo 10y ago
  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.
ris 10y ago
This is called "writing tests".

gedrap 10y ago

What exactly do you mean by 'errors were only triggered on runtime'?

RussianCow 10y ago

I'm not sure I really understand what you're saying, but in any case, this is a problem with any dynamically typed language, and isn't in any way specific to Flask or even Python. If writing applications without the guarantees of a "proper type system" is painful for you, then Python is probably the wrong language. That said, you shouldn't have to manually test anything—that's what automated tests are for. With regard to testing Flask applications specifically, there is a guide[0] in the docs that covers everything you need to get started. [0]: http://flask.pocoo.org/docs/0.11/testing/ http://flask.pocoo.org/docs/0.11/testing/

kerkeslager 10y ago

Are you unit testing?

doomrobo 10y ago
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.

ris 10y ago

This is called "writing tests".