Community mailing list archives

Re: The Speed of UnitTests

DevCO Colombia , David Arnold
- 08/16/2016 11:57:41
Thanks Alexandre, I could take away two interesting hints from the end of the referenced slides by Leonardo Pistone: 
- Functional Core & Imperative Shell (Gary Bernhardt) as a design paradigm
- anybox nosetests, but as I see on pypi, it has a lock in on anybox recipe and is not really a decoupled piece of tooling.

Still for new unit(!)tests, mocking seems like a viable option. The talk recommends "spec_set" but arguably it's more advisable to use "auto_spec" instead, as interface may change, and this is when you want your tests to become to fail.

Jairo and Nhomar:
I think Jairo has an argument. I've not gone that far to timetrack the remaining 13 y pico minutes, but there is a lot of disk involved, so I'll just suspect that. First there is need of a lot of reads per module to get data files loaded. Then there are quite some not so optimized database operation (see for example sqlalchemy with concept of work unit in order to see what I mean). I'm not sure, but I guess, by bringing @bwsandman's in memory sqlite3 mock to the next level (eg including an SQL Test Cursor into the core) could tremendously speed up at least the writing part of the above equation.

I think, a further distinction throughout the framework between unit tests and integration tests is warranted. While unit tests MUST not depend on data files, integration tests possibly can but should avoide that. Having this distinction, one could optionally get rid of the data loading part as well by a flag. I hope Odoo testing engineers happen to read this thread.

Best, David

El mar., 16 ago. 2016 a las 10:38, Jairo Llopis (<>) escribió:

2016-08-16 8:12 GMT+02:00 David Arnold <>:
The remaining 13 minutes and 17 seconds is plain vanilla module and data loading of all kinds with heavy DB writes.

What I read from that is that Odoo really needs lots of framework refactoring. In other words, Odoo is slow.

Jairo Llopis

Post to: