PHPUnit and Plugin Development

[mattsches]

Hi, since I heavily relied on unit testing in almost all my recent projects, I thought I try it out for some S9y plugins I've been working on. After some setbacks I managed to set up a more or less convenient way to run phpunit for plugins only.

I put the files on GitHub and added some instructions. I you find this helpful, please let me know.

I also blogged about it in German, am just realizing now that English would've probably been the better choice

If you have any questions, don't hesitate to post them here or on GitHub. Thanks
- mattsches

[mattsches]

*bump* As Timbalu currently (and correctly) pointed out, I didn't get a lot of reactions to this. I've been asking myself: why? Unit tests have been an essential part of every project I've been working on over the last years. And rightly so.

Yet I know that there are still developers out there who refuse to write tests, for various "reasons". I don't want to force anyone here to write tests, but I'm deeply convinced that S9y will eventually profit from increasing test coverage.

So, is there anything I/we can do? Maybe not everyone is familiar with phpunit (I would write a tutorial then). Maybe it's still too difficult to set up (It is! that's why I created the GitHub repo in the first place). Maybe everyone's too busy coding other important stuff (That's okay). But still: It's not that much more work to write a couple of test cases, is it? Why not start now?

We have to take into account two areas: core classes (and core plugins) and third party plugins. But let's start with plugins because they seem to be updated more often: What if everyone who updates a method contributed the respective test? Create a directory "tests" in the plugin dir and put the test case there.

I could also restructure the setup in a way that all tests reside in my s9y-plugins-phpunit repo, and, consequently, we don't push the test cases to additional_plugins but to my repo.

Opinions?

[garvinhicking]

Hi!

I can only speak for myself - I simply don't have the time for it; while writing unit tests in new environments is great because it helps your workflow, writing them for large existing projects can be a PITA. So I have to split my "awareness" time and allocate it for this project on where it both creates fun for me, and has some effective help for users.

Your suggestion to implement this "on the go" sounds good, but it might be hard to create relevant test cases for method changes. It could best be done on "real" methods that have algorithmic content (instead of "output/display" content, or general logic). Maybe we also just need more examples of this for others to jump aboard the wagon...

Regards,
Garvin

[mattsches]

I can only speak for myself - I simply don't have the time for it; while writing unit tests in new environments is great because it helps your workflow, writing them for large existing projects can be a PITA.

Thx for your reply, I totally understand that. I tried to wrap my head around what the nl2br plugin does yesterday - no fun indeed I have no problem with you as project lead taking care of other things.

Your suggestion to implement this "on the go" sounds good, but it might be hard to create relevant test cases for method changes. It could best be done on "real" methods that have algorithmic content (instead of "output/display" content, or general logic). Maybe we also just need more examples of this for others to jump aboard the wagon...

Right, I'm not even dreaming of a high coverage. Just sometimes (eg. nl2br) it makes understanding the methods under test a lot easier if there are test cases. So if anyone dives into code really deep and maybe even fixes a bug, then it would be great to have an additional unit test alongside it.

Providing more examples is a very good point. I will try to publish the plugin tests I've written so far to my repo.

[mattsches]

I had some time recently and - while refactoring the typesetbuttons plugin - thought a lot about making unit testing for S9y plugin easier. Writing tests first and refactoring the plugin after made the process a lot more straightforward - because I was always certain that things still worked as expected.

Anyway, I thought it would be nice if the unit tests would be run automatically after each commit (and push). Travis CI is used for this task by many OSS projects. So why not give it a shot for S9y?

Well, here are the results of my first attempt at running the additional_plugin tests on Travis. It's currently only triggered when I push a change to my personal fork of the main Serendipity repo, which obviously doesn't make much sense. But since it's more like a proof of concept, I'm happy it works

Matthias