#2550 closed task (fixed)
implement a test harness for 0.9 which does not rely on a build system
Reported by: | alex | Owned by: | alex |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | TestFramework | Version: | 0.4.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Dojo 0.9 must include a test suite that anyone can run from the command line or from a web browser without any build system or setup other than a checkout of the repository
Change History (42)
comment:1 Changed 14 years ago by
comment:3 Changed 14 years ago by
Status: | new → assigned |
---|
comment:4 Changed 14 years ago by
It would be great if the new test harness made it easy to test dojo functions that operate asynchronously. Back a few weeks ago we made a tentative decision to change the dojo.data APIs so that they support *only* async access, but the current JUM-based unit tests rely mostly on sync access.
Also, it would be great if the new test harness allowed for grouping a set of tests. Ideally a group of unit tests should be able to share some common helper functions, so we can avoid either (a) having the common helper stuff repeated in 10 different tests DRY, or (b) having the ten different tests glommed together into one mega-test, or (c) having the 10 tests rely on helper functions that are defined in a global namespace. (We accidentally got burned a couple times in the dojo.data unit tests, when two different unit test files both defined the same globally scoped helper function.)
comment:6 Changed 14 years ago by
comment:7 Changed 14 years ago by
brian,
so you're looking for something like a test suite concept? I guess I didn't implement it based on a felling of YAGNI since you can register anything (including an object, all of whose methods are tests). Would it be sufficient to give test groups setUp and tearDown methods somehow?
comment:8 Changed 14 years ago by
Hey Alex,
Just as an example of what i'm looking for, you might want to check out our existing unit tests for RemoteStore?: http://trac.dojotoolkit.org/browser/trunk/tests/data/core/test_RemoteStore.js
The test_RemoteStore.js file defines 5 functions that are unit tests (the functions with names that start with "test"):
test_data_core_empty() test_data_core_movies_sync() test_data_core_movies_async() test_data_core_movies_revert() test_data_core_movies_save()
The file also includes 3 helper functions, which are used by the unit test functions:
_test_data_core_newStore() _test_data_core_load_movies() _test_data_core_movies()
Each of the helper functions is called by two or more of the unit test functions. The helper functions have names that begin with "_" to prevent the test framework from considering them to be test functions and automatically running them.
Unfortunately, the test framework loads this test file into memory at the same time as all the other dojo.data test files, so the helper functions end up defined in the single global namespace that all the dojo unit tests are running in -- to prevent bugs caused by name collisions, the helper functions have painfully long names. The new test harness solves that problem by making it easy to use namespaces like tests.foo.bar.
So what I'm hoping for is just some way of doing the same thing in the new test harness but in a less hackish way -- some way of having a test file that defines 5 actual unit test functions as well as 3 helper functions that are available for the unit test functions to use.
I guess maybe this problem could be solved if a test group had setUp and tearDown functions, as you suggest. Then the setUp function could simply define the 3 helper function. But wouldn't the setUp function end up getting called 5 times, once for each of the unit test functions? That wouldn't be the end of the world, but it would be cleaner if the 3 helper functions only got defined once.
On a related note, here's a guy who argues that you don't really want setUp and tearDown functions at all, just helper functions:
http://www.agileprogrammer.com/dotnetguy/articles/SetupTeardown.aspx
And, also related, here's an article that talks about the usefulness of having a facility for FixtureSetUp? and FixtureTearDown? functions that only get called once for the entire test group, instead of (or in addition to) simple setUp and tearDown functions that get called once per test function. I don't have a ton of experience with unit testing, but to me the idea of FixtureSetUp? and FixtureTearDown? seems more useful than the idea of setUp and tearDown.
comment:9 Changed 14 years ago by
Doh, forgot the last link: http://www.codeproject.com/csharp/autp4.asp#Fixture%20Setup%20And%20Tear%20Down15
comment:10 Changed 14 years ago by
comment:13 Changed 14 years ago by
comment:14 Changed 14 years ago by
comment:15 Changed 14 years ago by
comment:16 Changed 14 years ago by
comment:17 Changed 14 years ago by
comment:18 Changed 14 years ago by
comment:19 Changed 14 years ago by
comment:21 Changed 14 years ago by
comment:23 Changed 14 years ago by
(In [7847]) adds support for:
- registering URLs
- loading of tests in loaded URLs
- automatic timeouts for loaded URLs
- automatic test creation from code strings
- improvements in use with dojo
- group-level setUp() and tearDown()
Also includes myriad bug fixes. Refs #2550. Still need to document many of these changes in the porting guide.
comment:24 Changed 14 years ago by
comment:25 Changed 14 years ago by
comment:26 Changed 14 years ago by
comment:27 Changed 14 years ago by
comment:28 Changed 14 years ago by
comment:29 Changed 14 years ago by
comment:31 Changed 14 years ago by
comment:32 Changed 14 years ago by
comment:33 Changed 14 years ago by
comment:34 Changed 14 years ago by
comment:36 Changed 14 years ago by
comment:37 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Marking fixed. Further improvements to the system should happen under separate bugs.
(In [7524]) refs #2550