Test suite for the occurrence import mechanism about gbif-alert HOT 4 CLOSED

Nice to see this @niconoe! 🥳
About filtering, I think it's better to filter as much as possible in the query and that only tests are performed from our side. This will make things easier to be reviewed also (if we doubt which data we used months ago, checking the download webpage will be easier). Or am I missing something?

from gbif-alert.

Update: I implemented the --source-dwca option (will make the script more flexible but also make testing a bit easier).

Things be be tested (to be refined):

• that we can import an existing file with --source-dwca
• that a correct request is sent to GBIF if we're not using the --source-dwca option
• that the maintenance mode is correctly set and released (blocked by #22)
• basic import works: correct number of occurrences
• basic import works: correct values for the occurrence records
• basic import works: a new DataImport is created
• basic import works: DataImport values are correct
• previous occurrences (replaced or not!) are deleted
• that some filtering is applied (absence records, no date, no location, ...)
• that entities linked to occurrences are properly moved to the new occurrence
• atomicity (see #62)
• emails are sent reporting the status
• raw values (strings) are trimmed
• ...

from gbif-alert.

Thanks @damianooldoni, very good point.

I can't guarantee that there will always be a GBIF filter available to suit our needs (in that case, we'll also need to keep a lighter filtering stage at import stage), but indeed the better approach is to filter as much as possible at the "generate download" step. I'll create a new issue to focus on this point (this one is primarily for the unit tests of the import mechanism).

from gbif-alert.

I think all was covered a long time ago.

from gbif-alert.