I've checked in some changes (19930) that re-enable our previously
disabled browser tests and add some more. We now are testing:
- That our command-line and prefs configurations get parsed correctly
and leave us in a good started state.
- That content scripts and user scripts actually modify loaded pages.
- That toolstrips load and basic functions work.
- That tab contents and toolstrips served from chrome-extension://
actually get extension APIs and can call them.
- That we don't crash in incognito mode.
I am really liking the InProcessBrowserTest system (jcampan++ for his
recent work on it). It takes some getting used to, and I don't think
it yet works on mac/linux, but it seems to be at the right level of
abstraction to do good integration testing without introducing a bunch
of test scaffolding.
I think we could test a lot more this way. For example, we could test
our APIs: not just that the renderer side of them work and throw
errors the right way like we are now, but that they actually result in
changes to the browser UI.
Of course, we should mainly still use unit tests. They are faster,
probably more reliable, and can test the fine details. But I think
with every major change now, we should consider a high level
integration test, too. They should be good for detecting that the
system as a whole is working sanely.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
