Set up automated unit tests

[MER-C]

Now that we're on Github, we have access to some CI tools e.g. Travis-CI. This would be great for running unit tests automatically.

[MER-C]

That was much less traumatic than I anticipated. Codeship can also automatically deploy to Google App Engine -- something we should make happen. This includes generating Javadoc.

[Nirvanchik]

Wow looks interesting. Are you talking about https://en.wikipedia.org/wiki/Travis_CI ? Also, generating Javadoc - is very suitable. But I saw it at https://wikipediatools.appspot.com/doc/index.html How did you do that?

I have just checked the page: https://github.com/integrations - really impressive.

[Nirvanchik]

~~Also, it would be nice to compile Wiki.java to JAR library and upload to Maven. I am very close now to the moment when I don't need patches to Wiki.java, or in other words Box version of wiki.java satisfes me and I can just fetch Wiki-java.jar with Ivy (Maven/Gradle/whatsever) and not copy-paste it to the project.~~ I apologize. Just stumbled upon #88

[Nirvanchik]

How do you like to write tests? by scope:

1. Go with just one "smoke" test for each feature. Feature works and we are fine.
2. Deep full testing. Test-cases cover all good & bad occasions, inputs & conditions for feature.

by infrastructure:

1. Mock everything. Mock fetch(), post(), mock HTTP responce.
2. Do not mock nothing (anything). No mocks. Test on real Wiki, on real Internet, on real data.

I see you chose 2) but instead of real Wikipedia you use test.wikipedia.org with test pages specially created for that. Hm. LGTM. Regular testing on real Mediawiki ensures stability and freshness.

[Nirvanchik]

I consider using getMax() instead of hardcoded "max" in "&tllimit=max" or similar. This is for testing. In tests you are not going to create 501 pages for your 1 test-case. You are ok with 2-3 pages and for that you should be able to set limit other than 500 (max).

[MER-C]

Codeship is similar. Two test classes are necessary because there are some things that can never be unit tested due to dynamic content (e.g. recentchanges). I would like the unit tests to cover as much as possible, but writing them is not particularly interesting.

[Nirvanchik]

What about using Mockito in tests? I know Wiki-java has no dependencies yet and this is cool. Mockito would be a dependency and break this ideal feature.

But you can't imagin how powerful and useful it is.

[maflcko]

I am not familiar with Codeship. Does it run on pull requests and return the result so it can be displayed on GitHub? Otherwise, I'd suggest using travis-ci.org.

[intracer]

Implemented Travis CI support #141

[MER-C]

Codeship allows direct push to Google App Engine, which is something I want to set up eventually.

[tiramon]

Testcase 'org.wikipedia.WikiUnitTest.diff' is failing since August 4th

[tiramon]

And after reading the discussion i like Mockito to fake remote content, works fine for my testcases Or PowerMock if you need a more powerful version and you have to fake output of static method etc.