Too often when developing Python web apps we first choose a framework and database, then code to their rules and restrictions. It's only later that we start thinking about our application's business logic. If we reverse the order and work on our logic first it can make code easier to test, and let us make more informed decisions of what frameworks and data-stores best suit our project.
When developing Python web applications, generally the framework and databases are picked first, then business logic is written to conform to what the framework dictates. This can lead to difficult to write and less effective tests, framework lock-in, and less informed decisions about what technologies should be used. This talk will discuss some of the issues of writing business logic in "framework" code, how to separate your business logic and treat it as a different testable application, and how to do TDD with this different methodology. Finally the talk will cover what this means in terms of how the architecture decisions you make might differ as a result.
The talk will begin by looking at the development process of choosing a framework first, in this case it focuses on Django and its built-in ORM. The talk will look at the procedure of creating a simple application, setting up models, writing business logic in views, and then testing the whole stack. It will also look at some of the advantages (quick POC-development, and packaging) and disadvantages (slow and arduous testing) of this method.
The talk will then discuss how to write your application by separating the functionality into discrete testable units: for sourcing data, performing business logic and generating data for output. By performing this separation each functional unit can be tested and developed individually, with mocks being used at the intersection of the layers.
Once the business logic is developed it needs to be re-integrated with the web framework. The talk will cover some methods of integration and deployment with the stack of the rest of your application.
Once each "edge" of the application has been tested, what happens if the mock functions that have been written turn out to actually be useful for production? The talk finishes with how developing in this style could mean better architecture decisions for your project.