Flask

I have written before about Flask and obtaining test coverage results here and with an update here. This is pretty trivial if you’re writing unit tests that directly call the application, but if you actually want to write tests which animate a browser, for example with selenium, then it’s a little more complicated, because the browser/test code has to run concurrently with the server code. Previously I would have the Flask server run in a separate process and run ‘coverage’ over that process. This was slightly unsatisfying, partly because you sometimes want coverage analysis of your actual tests. Test suites, just like application code, can grow in size with many utility functions and imports etc. which may eventually end up not actually being used. So it is good to know that you’re not needlessly maintaining some test code which is not actually invoked. ...

Introduction Typically routes in a web application that require login are explicitly marked as such. Whilst routes that are open to general (anonymous) users, are left unmarked and hence implicitly do not require login. Because the default is to allow all users to visit a particular route, it is easy to forget to mark a route as requiring a login. I’m going to show a small pattern for making sure that all routes in a web application are explicitly marked as either requiring login or not-requiring login. As an example this will be done in a Python, Flask-based web application using Flask-Login but the general idea probably works in at least some other Python web application frameworks. ...