[Webkit-unassigned] [Bug 21010] WebKit needs C++ Unit tests

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 27 11:43:14 PDT 2009


eric at webkit.org changed:

           What    |Removed                     |Added
                 CC|                            |darin at apple.com,
                   |                            |ggaren at apple.com

------- Comment #6 from eric at webkit.org  2009-03-27 11:43 PDT -------
I've been thinking about this further.  My current work refactoring work in
editing would be helped greatly by being able to unit test the classes I'm

Thinking through general design issues:

1.  Unit tests should work in Debug builds, but need not work in Release
builds.  (This allows us to depend on debug-only functionality).

2.  I don't think we want to re-invent the wheel.  I'm not familiar with all
c++ testing frameworks, but there seem to be numerous (CPlusTest ships w/ OSX,
gunit is what Google uses for everything, I know there are others).  The simple
functionality is easy, but there are lots of bells and whistles w/ other's

3.  Unit tests should be built as part of the normal process (or even if the
tests aren't built as part of a normal build, building the tests should not
require a special build of WebCore/JSC, etc.)

To satisfy goal 3, I can see two solutions:
1.  If unit test code is built outside of WebCore then WebCore Debug builds
will need to expose some extra symbols for the unit tests.
2.  If unit tests are built inside WebCore, a single symbol (runTests()) needs
to be exported, and all the unit test code will need to be guarded in !NDEBUG
#ifdefs to prevent it from getting built into a Release/Production binary. 
This approach could directly conflict with goal 2 above (not re-inventing the
wheel), as this would require linking in a bunch of 3rd-party code into WebCore
debug builds which could be undesirable.

I'd be interested to hear other's thoughts.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list