Closed Bug 700920 Opened 13 years ago Closed 12 years ago

Need an import module to test import implementation in mailnews core.

Categories

(MailNews Core :: Import, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 15.0

People

(Reporter: hiro, Assigned: hiro)

References

(Depends on 1 open bug)

Details

Attachments

(2 files, 4 obsolete files)

We need an import module to test import implementation in mailnews core to avoid regression such as bug 698987.
This patch modifies the AbImportHelper. - Create GenericImportHelper class which is parent of AbImportHelper and MailImportHelper. - Remove 'aType' argument from constructor of AbImportHelper. The type is defined by the file extension(i.e. '.csv' or '.ldif'). - To avoid confusable, change module name to search for. '.csv' -> 'Text file' MailImportHelper compares imported mail folders to the directory which is pointed by the third argument of the constructor of MailImportHelper. Currently it compares just directory structures not files in the directory. I mean, it compares tree structure of the mail folders and the directory for test of bug 698987.
Attachment #573079 - Flags: review?(dbienvenu)
Attached patch Part2 - the import module (obsolete) (deleted) — Splinter Review
This is it.
Attachment #573080 - Flags: review?
Attached patch The test for bug 698987 (obsolete) (deleted) — Splinter Review
I just want this! Mercurial does not allow empty directory, so I just add some empty file in directories which are used in the test code.
Attachment #573081 - Flags: review?(dbienvenu)
Attachment #573080 - Flags: review? → review?(dbienvenu)
Assignee: nobody → hiikezoe
Blocks: 684455
thx very much for the patches. They look reasonable, but they crash when run in debug mode, because the import code causes a lot of thread-safety assertions, and assertions make xpcshell tests fail. I'm not sure if there's a way for a given xpcshell test to turn off assertions. Fixing the assertions in the import code is ultimately the way to go, but that would require some significant re-structuring of the code, I think. I also didn't see this test run when I did make xpcshell-tests from the mailnews directory. Not sure what that is, because it looks like you've done the right thing with the makefiles and xpcshell.ini files.
Comment on attachment 573079 [details] [diff] [review] Part 1 - preparation of the import module . Create MailImportHelper similar to AbImportHelper Thx again for the patch. This comment is no longer right, since it refers to addressbook: +GenericImportHelper.prototype = +{ + /** + * GenericImportHelper.beginImport + * Imports the given address book export and checks the imported address book + * with the array in addressbook.json if aAbName and aJsonName were supplied + * to the constructor. + */ Other than that, it looks OK, but I'm going to pass the review to mconley, since he's more up to speed on AB things...
Attachment #573079 - Flags: review?(dbienvenu) → review?(mconley)
Comment on attachment 573079 [details] [diff] [review] Part 1 - preparation of the import module . Create MailImportHelper similar to AbImportHelper Review of attachment 573079 [details] [diff] [review]: ----------------------------------------------------------------- So this looks OK to me. I'm not a huge fan of the explicit checks for the type of the module ("mail", "addressbook"). To me, that's just screaming for a factory - but I think, now looking at your code, that that might be some overengineering - since you need those "mail", "addressbook" strings to get the import interface. Also, I found an erroneous comment for GenericImportHelper. Other than that, it looks pretty good. r=me, modulo the comment change, and a try build passing all of the tests. ::: mailnews/import/test/unit/resources/import_helper.js @@ +4,5 @@ > // used by checkProgress to periodically check the progress of the import > +var gGenericImportHelper; > +/** > + * GenericImportHelper > + * A helper for Address Book imports. To use, supply at least the file and type. Hrm - I don't think this comment is true anymore, since (as far as I understand), GenericImportHelper is a generalized import helper for both address books and mail.
Attachment #573079 - Flags: review?(mconley) → review+
Attached patch Revised part 1 patch (deleted) — Splinter Review
Carrying over review+ Addressing review comments. I pushed a try, but unfortunately there is an issue to run xpcshell tests. It seems to be caused by missing md5 module of python. http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=30246285b538
Attachment #573079 - Attachment is obsolete: true
Attachment #575002 - Flags: review+
Blocks: 703175
I re-tried two tries. http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=f08f98025c52 Unfortunately this time xpcshell tests in toolkit/places failed on WinXP. So I tried again on WinXP. http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=cab9de82424b This time all xpcshell tests passed.
Blocks: 124486
Depends on: 729676
Attachment #573080 - Flags: review?(dbienvenu)
Attachment #573081 - Flags: review?(dbienvenu)
Attached patch Rewrite with new ImportMailbox interface (obsolete) (deleted) — Splinter Review
Attachment #600566 - Flags: review?
The test in comment #3 causes the following assertion: ###!!! ASSERTION: nsCOMArrayEnumerator not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /home/zoe/hg/comm-central/objdir-thunderbird/mozilla/xpcom/build/nsArrayEnumerator.cpp, line 161 I've filed bug 730498 for the assertion.
Depends on: 730498
Attachment #600566 - Flags: review? → review?(dbienvenu)
Comment on attachment 600566 [details] [diff] [review] Rewrite with new ImportMailbox interface looks good, one nit, + var name = Cc["@mozilla.org/supports-string;1"] + .createInstance(Ci.nsISupportsString); can you use let instead of var here?
Attachment #600566 - Flags: review?(dbienvenu) → review+
Attached patch Revised patch (deleted) — Splinter Review
> + var name = Cc["@mozilla.org/supports-string;1"] > + .createInstance(Ci.nsISupportsString); > > can you use let instead of var here? Done.
Attachment #600566 - Attachment is obsolete: true
Attachment #604204 - Flags: review+
the two revised patches are ready for landing, I believe. Hiro, if that's not correct, let us know, thx!
Keywords: checkin-needed
Attachment #573080 - Attachment is obsolete: true
Attachment #573081 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 15.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: