Create a unit test system for the Mozmill APIs themselves.



Testing Graveyard
9 years ago
2 years ago


(Reporter: cmtalbert, Unassigned)



(Whiteboard: [mozmill-2.0+])


(1 attachment)



9 years ago
I think we can use the Mozmill JUM api for this, and we don't need to create anything at all.  But we need to write the tests for the elements lib API and the controller API.

Steps for this:
1. Ensure the JUM interface will work for us (pretty sure it will)
2. Write tests
3. Check tests in.  As these are unit tests for the mozmill APIs themselves, I think we should check them in to the Mozmill source code repo.  That way when a developer for Mozmill writes a patch it will be trivial for his patch to include the necessary test as well.

And once we have these tests we need to enforce adding a test with every change to these APIs.  I'm rather ashamed we haven't done this yet.

Feel free to discuss/refine the proposal below...
Everything works that way. See bug 498538 as an example. The test you can find here:

Tests should be checked in here:

Eventually we should create an extra folder for unit tests itself. So we don't collide with existing example tests. But finally we should cover all this work on the bugs itself by using the in-testsuite flag. That way we can directly see where tests are missing.
Hardware: x86 → All
Severity: critical → major
Some of those tests are very out of date at the moment. We should remove the preferences test and a few others as they were really just sample tests we wrote when building the API and don't explicitly test mozmill itself.

Comment 3

9 years ago
Replying to comment 1 and 2, yes Henrik that is where we should put them.  And there is definitely old cruft in that directory, so this bug is needed to get us into a state where we can easily land new tests, which means svn deleting the cruft that is currently in there.

Once we have the directory structure setup, the idea of how the tests ought to be written and a few tests checked in, we can close this bug, and track places where tests are needed using the in-test-suite flag
Whiteboard: []


8 years ago
Whiteboard: [] → [mozmill-2.0?]

Comment 4

7 years ago
The framework for this tester has landed in

We just need to wire the tests in to close this bug.
Whiteboard: [mozmill-2.0?] → [mozmill-2.0+]
Created attachment 522777 [details] [diff] [review]
Wire tests into Mutt framework

I also made some changes to, so that it a) uses the correct ManifestParser subclass (which allows us to automatically ignore disabled tests) and b) doesn't search for all-tests.ini in the cwd, but rather its location relative to
Attachment #522777 - Flags: review?(ctalbert)
The full diff which includes moving all files from mozmill/test to mutt/tests can be found here:
Comment on attachment 522777 [details] [diff] [review]
Wire tests into Mutt framework

Re-assigning to Jeff as Clint is busy and we probably want this now.
Attachment #522777 - Flags: review?(ctalbert) → review?(jhammel)
(not to say that Jeff isn't busy)

Comment 9

7 years ago
Comment on attachment 522777 [details] [diff] [review]
Wire tests into Mutt framework

+                                       default=os.path.join(os.path.dirname(__file__), "tests/all-tests.ini"),

This should almost definitely be  `os.path.join(os.path.dirname(__file__), "tests", "all-tests.ini")`

+        results = test_all_python(mp.active_tests(type='python'), options)

This will work for now.  manifestparser should probably be improved such that this actually does what it should, but that's another story that I don't want to go into here (ping me in #ateam if you care)

r=me if you fix the os.path.join issue
Attachment #522777 - Flags: review?(jhammel) → review+
Last Resolved: 7 years ago
Resolution: --- → FIXED


2 years ago
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.