Unit tests [with PHPUnit]

[ifireball]

I wrote some unit tests for TT-RSS, focusing on the DB code for the time being.
Since fox doesn't want this in the main tree, I'm sharing this here. The tests could be run by merging with the "master" branch of my repo (My branch is currently frozen on v1.7.8 but the code will probably merge cleanly with any version since all added files are in a separate directory):

https://github.com/ifireball/Tiny-Tiny-RSS

I've included some instructions about how to install PHPUnit and run the tests in the "tests/README" file.

I would love it if some people try and play with this, especially if someone could try this with PgSQL (Will probably need some minor tweaks in the code and SQL files) since I only have MySQL installed here ATM.

[Skibbi]

I could play with those tests in my spare time, but can you tell me what should I report back?

[ifireball]

Well, they all should run successfully for now, that is the point of unit tests, you know that while they succeed, your changes to the code did not prevent it from doing what it is supposed to do.
This is the first step if you want to do some deep-level re-factoring.

[phz]

I could play with those tests in my spare time, but can you tell me what should I report back?

Tests should be a mirror of the documentation and intended function. Ideally, all documented behavior should have a corresponding test in a project. Many even encourage programming in the steps

1. documentation
2. writing tests
3. actually programming

in different iterative processes.

In "commercial grade" software, tests are often integral to the extent that functionality that lacks a test function is regarded as a bug (fixable by writing the test in question). Without tests, stuff will break from time to time. In personal projects that might not be the end of the world, but having tests can save time in the end, especially if it is a project that runs for a long time.

One of the best parts of tests is the comfort they bring. With well-written tests, you know that the program works as intended, no matter how much hacking you've done. This gives the programmer a large amount of confidence and good night sleep. This is a big saver if one returns to code written six months ago to make some change, since one is no longer in the mindset of that code and might very well miss subtleties (e.g. "fixing" something, and then finding out the hard way that old interfaces relied on a certain exception being raised).

So relevant feedback would probably be the suggestion of new tests to cover more functionality (preferably with code written and tested, as always ), reports on tests that could be changed to better reflect current functionality, better documentation of the tests themselves, etc.