The new in process browser test framework creates a headless browser-like environment where rich cross-sectional tests can be run as unit tests rather than as ui tests. UI tests are a PITA and so this is very enticing.
One issue we've had with so far is that many objects implement singletons in an ad-hoc way, sometimes caching pointers to objects that later get destroyed. Since a browser startup sequence is simulated (by a call to BrowserMain) for each run of an in-process browser test, when you run multiple in-process browser tests in the same unit_tests.exe run you will eventually crash somewhere. One solution is to have all singleton objects derive from base::Singleton, and use the base::AtExitManager to shut them down cleanly at the end of each test run. The only question is - how many ad-hoc singletons are there? Does this conversion seem reasonable? What challenges do people foresee? On a related note, with the commencement of the fixit week next week we're going to get a lot more strict about requiring tests for functionality. Barring the above issue, the in-process browser testing framework makes it relatively simple to write tests for complex functionality. I think we should require tests be written using this tool if applicable and have the tests be disabled if they fail when run in combination with others, so they don't turn the buildbot red, with the idea of fixing the framework at the same time and then turning them all on. The tests will pass when run in isolation. -Ben --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
