the time taken to write something that mocks a database is orders of magnitude more than just testing on a separate database instance. As for "decoupling", I'm a big believer that webapp tests should need to be executed with behavioural tests, not unit-tests. Of course business logic core modules (if any) can be tested with unittest, but that's actually "outside" the scope of web2py..... they're just standard python modules if you kept them just "business logic" and they don't interfere with presentation logic.
Il giorno giovedì 16 maggio 2013 10:31:27 UTC+2, Arnon Marcus ha scritto: > > 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.
