On Thu, May 16, 2013 at 9:18 AM, Arnon Marcus <a.m.mar...@gmail.com> wrote: > > > For unit-tests, people doing TDD want interactive-performance. They > configure watchers on their files, so the tests run locally each time they > save them. > It means, their entire test-suite of unit-tests should run in a > second-or-two, preferably less.
I like this subject a lot. It's not about tests, actually. It's about architecture. ;-) You're absolutely right, Arnon! In a large system, though, it is difficult to run all the test suite in a few seconds. To address this problem, you can run just tests that cover what you changed. This is the unit test approach: isolation, right? Conceptually, a unit test will test some atomic code, i.e., a piece of software in isolation. If your architecture is good, you'll achieve that. To address it, try to put your code to be unit tested in modules. So, it's decoupled from your "delivery mechanism", what the web really is. > How many times do they expect to run them in a day? Hundreds. Thousands! It must be multiplied by the number of developers your project has. > I have seen several lectures showing live testing-sessions that run hundreds > of tests in less than a second. > You can not do this if your unit-tests are using a database. > The minutes-scale of tests, should be integration-tests, not unit-tests. I've been studying Uncle Bob's Clean Architecture approach [1]. Graphically, it divides your system in circles, to help control what has access to what. It's a nice approach. He counts on dependency injection, but it's not a simple way do develop software. Every performance problem when running a unit test can be considered a "smell". Usually you have a coupled design. But I understand we could follow the Zen of Python, claiming more for practcality than for purity. I see that developing a real decoupled application doesn't help in most cases. Mainly in the small apps world. [1] http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html > These are usually ran somewhere-around 5 times a day per-developer, > according to what I've seen. It's not the TDD approach, though. If Arnon is talking about TDD, it's not useful to limit how many times a test suit can run. Ultimately, all tests will not be run, due to slowness. >> >> uhm2. This is just asking for nightmares. If you want speed (don't want to >> involve a database) you test "transformations", not the fetch-transform >> couple. Yes, but there's a light in the path. There are 2 performance problems with integration tests: a) the database b) the application server With web2py.test [2] I try to address both. The DB part, I mimic what Django does to speed up tests in need of a database: create a in memory database. The application server part, I clone the Web2py environment, simulating a shell environment. You have db, templates, but you don't have a real request. Actually, you don't even need to have the server running (web2py, or apache, or nginx). Yes, there are drawbacks in both scenarios. But it exists in any test envoronment. Django's testclient is more robust and give us out of the box some tools to work on tests, but I think Web2py can evolve in this area, to have a better acceptance to a test based development workflow. [2] http://github.com/viniciusban/web2py.test >> > Sure, but you want to use your existing business-logic core, which usually > contains db-object-usage... > It's not a nightmare to monkey-patch these objects/calls like that, it's > actually a pretty common pattern. You even don't need to monkey patch anything. You need only a integration test. It's simpler. >>> >>> You could theoretically monkey-patch this whole statement in it's >>> entirety (or any part of it), so it returns whatever you want (say, a >>> pre-made 'rows' instance with 'row'-instances inside) >>> The 'mock' library should allow you to do that, wile constraining the >>> monkey-patch to a temporary execution-context, and tear-it-off automatically >>> at the end of the test (either with a decorator, or a context-manager that >>> is provided in the library) No. You just need a in-memory database. ;-) -- --- 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.
