Write tests

Started off with this little test case. Only added one starter test now to look for the welcome screen. Passes :) Obviously this is all just a start, and we need way more tests here. Committed this though as a signal that we should expand on the testing coverage.

Added little coverage for adding languages. Note that the second assert is funky due to not having strings to translate yet. We might need to rework the parsing API a bit to make it easier to test, we will see. Anyway, this adds a little bit of language testing. Looong way to go :)

Worked on adding parsing/import/project creation in the tests.

- Added an l10n_test.module which purposefully lacks an .info file to not show up in the module list. But for potx it just looks like a module, so things like text in a menu hook are parsed.
- Created a temporary packages directory and enabled l10n_localpacks to work with that.
- Used Archive_Tar to tar up this l10n_test.module to a package.
- Used the l10n_localpacks scanner to find, extract and parse the package.
- Verified that the project and language lists now show up and the parsed project has a project page with one release known and parsed.

Next up is looking for the exact strings and testing filters.

Ps. committed this addition. All tests still pass :)

I've actually reworked the potx testing part to #571538: Add tests to translation template extractor and added a huge amount of tests there, so we have Drupal 5, 6, 7 module parsing and .info and .js file parsing covered.

Going to work on the above to reuse those tests files instead of doing our own l10n_test.module, so we can just grab the stuff from there and parse that up into the DB.

Integrated with the aforementioned potx API tests, so now we have three projects imported into the database for three different APIs parsed: Drupal 5, 6 and 7. Next up now is to actually test whether we have the right strings in the output, that is almost the same as in the potx tests, but we are checking the web output.

- Added another release for the 6.x test project, so we have two releases, one with and one without JS strings. This allows us to look into the strings more deeply.
- Added string matching, so we can verify version patterns, and whether they are reflected in the DB.
- Added filtering for the two D6 releases, so we can look for their difference as well.

Next up is the other filters: context, contains, etc.

Then we can look into adding some suggestions and translations and checking filtering for them too.

Look ma! These tests found issues with l10n_server :)

I've just added these additional tests which found the issues (see below):

- Added a new "member" user who can submit suggestions
- Fixed 'limit' bug (see below)
- Added exact counting of strings found on the examined pages, so we don't only look at our sample, but the exact number too
- Added tests to filter for context and context&project
- Added tests to filter for "string contained" also combined with project too
- Added tests to verify the more info lookup feature to verify that a string was related to the given projects

- Added tests for submitting suggestions (for simple strings, strings with context and plural strings :)
- Added tests to check that the suggestion lister Ajax callbacks return our suggestions
- Added checks to our listing based on the suggestion filters (found a bug, see below)
- Fixed issues with double escaping data in asserts (this was due to copy-paste code from simpletest itself which has the same double escaping bug - submitted at #572564: Assertion message generator double escapes data)

Bugs found while working on these tests:

- The simpletest bug at #572564: Assertion message generator double escapes data
- That my latest patched code from #570648: Add mass moderations screen for suggestions (+ user filtering) did not validate the limit argument properly, thus allowing for arbitrary limits to be set -- now limited to the allowed values only
- That the existing (unpatched) l10n_server DRUPAL-6--1 code had a bug with filtering for strings with no suggestions; we only matched for t.has_suggestion = 0 which assumed an actual row in the translation table, while strings lacking suggestions usually have no such row (AKA strings which never had a suggestion or translation before for the given language) -- because I'm working towards testing and inclusion of #570648: Add mass moderations screen for suggestions (+ user filtering), I'll try and fix this issue there; it was just a small change in the query builder

- Added one more member and a moderator
- Attributed later suggestions to member_2 and asserted appearance of that in the detailed outputs
- Added mass moderation tests, with testing for filtering on the mass moderation screen (found bugs, see below)
- Added actual testing for mass approval of items on the moderation screen
- Added more suggestions and a translation with the moderator user and tested for that
- Gone back to the translations view screen, now that we can test for (combinations of) the status options; added such tests
- Also added translation filtering per user (one added directly, the other approved via the mass approval screen)
- Added testing for the mass decline feature too
- Added tests for the individual decline and approval Ajax callbacks

This all makes me confident that we can add the changes in #570648: Add mass moderations screen for suggestions (+ user filtering) to the module, since the tests cover that and found (hopefully most) bugs in them.

Bugs found with the above new tests:

- The project filtering in the mass moderation screen were not using the right variables, was not actually working
- Context filtering UI was there, but was not implemented; also, context display was missing on the UI

Fixed these bugs to be committed in #570648: Add mass moderations screen for suggestions (+ user filtering).

Next up would be testing of import and export which should then complete testing of an overwhelming portion of the module.

Found that the scan tests failed in finding the right text on the output, but otherwise each task was completed. Seems like some PHP versions lead to absolute paths returned from tempnam(). Attached patch devised and being committed to always use full path names and then replace that to shorter path names to match the output from the scanner. All tests pass again on my environment.

Taking writing import tests under #610768: Clean up import UI, fix last string bug and add tests. Export tests are still needed.

Should not leave this open forever. While we need more tests to be added, this issue can be considered fixed. Opened #690424: Add testing for exports for the exports.