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.
Unit tests [with PHPUnit]
Unit tests [with PHPUnit]
Last edited by ifireball on 08 Apr 2013, 02:00, edited 2 times in total.
Re: Unit tests [with PHPUnit]
I could play with those tests in my spare time, but can you tell me what should I report back?
Re: Unit tests [with PHPUnit]
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.
This is the first step if you want to do some deep-level re-factoring.
Re: Unit tests [with PHPUnit]
Skibbi wrote: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
- documentation
- writing tests
- actually programming
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

Who is online
Users browsing this forum: No registered users and 8 guests