This sound great, I am currently researching testing-options for web2py, and py.test is one of my leading candidates. I haven't read passes the readme yet, but I plan to - it's a good news to see that there is something being actively developed/maintained and up-to-date for doing this.
I have some questions/comments though: I've been watching many lectures on testing in python lately (mainly from PyConfs), and there is a lot of discussion on what should be unit-tested, and what should be considered higher-level (functional/system/integration). For example, it is generally considered bad-practice to thing of controller-action tests as 'unit-tests', because there rely so heavily on so many external-dependencies and environment-state. Therefore, the suggested approach is to keep controller-actions (called 'views' in Django-land) as small as possible, and externalize all logic into a separate modules, that do not require the general-environment as dependencies. Controller-actions are best though-of as being better-suited for integration-tests, which should be fewer, and much far-between, when compared to unit-tests. In addition, the suggestion is to not mock-out the templates, and actually test their logic - meaning, to use the templating-engine of your framework in conjunction with your actual template-code, to gain optimal test-coverage. The assertions should be on the output of the template-renderings, and something like WebTest for mocking-out the request-objects, and asset-over the returned response-objects. There is also a discussion about database-access - generally, you shouldn't do it - for performance-reasons - you should mock the models-layer. But then there is also a general suggestion against mocking the persistence-layer, as it is generally a very large and complex layer, with very broadly-defined boundaries. So the suggested approach, is to mock-over the 'model-using' code (the dal-using code). Meaning, using something like Michael-Foord's 'mock' library for monkey-patching the code that uses the db object. Another discussion revolves around decoupling, and strives for usage of dependency-injections. This is especially relevant for the above-mentioned data-layer mocking. It is suggested that the code would be structured in a way that would allow unit-testing the business-logic code without using actual database-accesses, through dependency-injection approaches. what I read this to mean, is that you should have your business-logic code in a separate module, that receives a db object from the outside. This way, you could provide a mocked/monkey-patches version of the db object, when unit-testing. This fake-db should be constructed in the setup-area of your testing code. What are your thoughts on these suggestions? -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
