Self Testing PHP Code

[adamreiswig]

I have been hearing a lot lately regarding self testing code for java, perl, python and more. Is there a solid method for accomplishing the same in php? I'd like to write tests for php class but can not seem to locate any information regarding this anywhere. Thanks for any help! Even if there are only half-baked methods, I'd still be interested in knowing about them.

[lastcraft]

Hi...

I'd like to write tests for php class but can not seem to locate any information regarding this anywhere.

Do you mean via assert() calls, unit testing (JUnit) or contracts (JContract, Eiffel). PHP has an assert method. It also has umpteen JUnit variations: PHPUnit, SimpleTest, PEAR::PhpUnit, etc.

I know of no tool to enforce contracts though.

yours, Marcus

[adamreiswig]

Do you mean via assert() calls, unit testing (JUnit) or contracts (JContract, Eiffel). PHP has an assert method. It also has umpteen JUnit variations: PHPUnit, SimpleTest, PEAR::PhpUnit, etc.

I know of no tool to enforce contracts though.

Honestly, I am to new to the concept of self testing code to know exactly where to start. I found a good article by a Martin Fowler regarding his experience with self-testing code. He mentions coding tests before coding functions/classes which help keep the programmer focused on the "interface for the new feature rather than the implementation." Also he mentions running all tests often so that as you integrate no features you'll know as soon as have an issue rather than only testing every so often and having to do a lot of back-tracking in bug searches. His describes tests that can be completely automated. He creates a collection of all his tests created and then they get run every midnight or whenever. Each time a new function is needed a new test is created and all these tests stay with the project code to be run whenever needed.

What I am looking for is mostly pointers as to how I can implement the same in my php classes via the most practical method(s) available and how I can automate these tests.

I found another article in which the author states that self-testing in php is difficult "because it can't be easily executed from the command line, yet. It seems impossible to write self-testing php applications." He is a great proponent of Perl in place of PHP. I'd like to find out if this guy is correct or not.

Sorry for the ramble but this is what I am trying to learn. Especially since testing code properly done is said to be a great time/headache saver in the long run. Thanks again!!

[Widow Maker]

Could be an interesting concept, though if it's new for Java, et al then I can see it being a while before it filters over to PHP ?

I've yet to begin Unit Testing myself, and assertion is new to me as well, so I'd welcome more information as well

[josheli]

marcus was too humble to mention it, but look at his simpletest framework.
http://www.lastcraft.com/simple_test.php
it should help get you started/give you ideas.

[Selkirk]

I've used assertion based testing before with good effect. One one project, we were able to introduce assertions into a program that was a quivering mass of unrepeatable GPFs and turn in it into a rock solid program. This was in Delphi. Each deference got an assertion to catch null pointers. (There are betters ways, the best is to use a garbage collected language.)

Assertions are a good complement to unit tests.

Unit tests are good at testing the public interface of a class. If you want to get inside the class, then unit tests start to have problems. You need to resort to techniques like mock objects and methods placed for the sole purpose of exposing internal details for testing. Of course with PHP 4's lack of access control, its easy to break the encapsulation of a class and call what methods or check whichever variables you would like.

In fact, there is a problem with unit testing: testing too much. If you start testing more than just the public interface of the class, then the tests cease being a safety net that makes you feel good about doing complex high wire acrobatics and becomes a straight jacket that prevents you from doing any acrobatics at all. When the unit tests are too intimate with the internals of the code, they can slow your development in stead of speed it up.

Assertions are internal to the code and are perfect for testing internal assumptions, such as those in your private methods. The assertions only work when they are executed, so you still need tests cases to exercise the code. Assertions are good at the low level routines in your code, when they are called in a complex situation. As higher level code is executed, the lower level assertions do their work. I find this type of testing is hard to do with standard unit testing.

Maybe I'm just not that good at unit testing yet.

Assertions are also good at giving you an executable representation of an assumption that you have made in the code. Done right, they are executable documentation.

I used assertions alot in Delphi and in C, but haven't really been using them in PHP. I think it may be more comfortable to use them in a language with a preprocessor.

[lastcraft]

Hi...

What I am looking for is mostly pointers as to how I can implement the same in my php classes via the most practical method(s) available and how I can automate these tests.

It is not so much self testing you are after as unit testing.

This piece of self promotion is a bit more blatant that the last . You probably want "Test Driven Development", part of the "eXtreme Programming" group of methodologies. There is an article on Developer spot...
http://www.developerspot.com/tutoria...ent/page1.html

See also Harry's early article on the subject...
http://www.phppatterns.com/index.php...leview/33/1/2/

yours, Marcus

[JonR]

SimpleTest's documentation is some really good stuff and mock objects, web testing, and super fast replies on the mailing list put it way above PHPUnit for me.

Blowing my own trumpet, for automation/reporting of test runs you could have a look at Rephlux, a project I've been working on to exactly that end. It's pure alpha at the moment and has plenty of limitations (some of which are detailed at the link) but you may find it useful.

Cheers,

Jon

[lastcraft]

Hi.

Assertions are a good complement to unit tests.

It is interesting to compare contracts as well with unit tests.

To write a unit test you need very little upfront knowledge of the design. This means that it doesn't constrain your solution with preconceptions. Additionally they are completely separate from the code and so don't clutter it. The downside is that you cannot prove a program with such tests. It is a bit like trying to paint a piece of paper black with an infitessimally small pencil. You can put dots everywhere, but you will never cover the piece of paper. Hopefully if you put enough dots down your confidence increases and that's still pretty good.

Contracts on the other hand say something very definite about a definite area of your metaphorical piece of paper. You make a statement about all inputs and outputs. The trouble is that in order to write a contract you must know so much about the design that the final coding is probably pretty trivial. Contracts prove the code in the presence of a correct design whereas testing is trying to prove the design and code together. Unfortunately for contracts in enterprise development, it is the design that is often the hard part. The contracts tend to clutter the code somewhat in the way comment blocks do.

Types are pretty much a very weak contact. They have minimal code clutter (except for declarations). Interfaces enforce minimal requirements across libraries. They are the lightest contract of all.

Assertions are purely about internals (as Jeff says) and are for the programmer only. For me it is not just unit testing that has killed them off , but that these days I just write smaller methods. As a result an assertion rarely tells me anything a test doesn't. They add clutter directly in the code although, like types, may aid in documenting it.

yours, Marcus

[dagfinn]

SimpleTest's documentation is some really good stuff and mock objects, web testing, and super fast replies on the mailing list put it way above PHPUnit for me.

The really tragic thing about PHPUnit is the lack of documentation for the new version. The documentation in the PEAR manual is still for version 0.?, and the interface has changed significantly. The only real documentation (unless something has been published recently) is Schlossnagle's book, which has a whole chapter on unit testing based on PHPUnit version 1. I copied the examples painstakingly from the book , but unfortunately they didn't work.

[JonR]

Hi

The really tragic thing about PHPUnit is the lack of documentation for the new version.

There's a paper on Sebastian Bergmann's site with some very brief details about the new version (on the talks page, under english, Testing Object-Oriented....). The pdf mentions that the new version 'aims at "api similarity " with JUnit so that existing documentation can be leveraged'.

Cheers,

Jon

[HarryF]

Just a side note - they've started using phpDocumentor to generate the API docs for PEAR packages automatically and it seems to run the moment you upload a releaes. If you check out the docs page for XML_Parser you'll see it divides into "user documentation" (the stuff that never gets written) and API documentation.

Another note, on topic, it Sitepoints article Effortless (or Better!) Bug Detection with PHP Assertions which focuses mainly on the assert function.

[Widow Maker]

Schlossnagle's book, which has a whole chapter on unit testing based on PHPUnit version 1.

Interestingly, this might actually be the thing I'm looking for to get me started with Unit Testing

Does anyone have an Amazon link I can look at ? Thanks

[sweatje]

Does anyone have an Amazon link I can look at ? Thanks

Widow Maker, shame on you for making such a request . Surly George's last name in unique enough to return relavant hits on the first page of an Amazon search.

[Widow Maker]

Sorry, your right of course

My appoligies folks

--EDIT--

Just gone and ordered the book from Amazon just 2 minutes ago Should get it for the end of the week with any luck