[TYPO3-dev] Unit testing suggestions

Dmitry Dulepov dmitry.dulepov at gmail.com
Fri Apr 30 08:45:26 CEST 2010


Hi!

Oliver Klee wrote:
> as promised, here are some suggestions on how to improve the unit tests.
>  I hope that they are useful to you. :-)

Thanks! I'll look at it again when I am back from vacation but I have some
quick comments already.

> +	protected $indexer;
> 
> I propose to rename this variable to $fixture (because "fixture" in unit
> tests usually is an instance of the tested class).

Well... "fixture" does not say anything. I think "indexer" is much better,
though it may not be inline with general practice. If somebody looks inside
the test, he wiull have no problem understanding what "indexer" is but will
have troubles with "fixture".

>    - @param/@return if you are using data providers (which you are not)

True :) I am just used to always have @return because it helps me to
identify the return type very quickly and also helps Zend Studio to show
function result type. When there is no return type shown, it causes me to
stop and look at it because it is potentially bad documented stuff. Thus I
always put @return even when it does not make much sense from the code
view. It pays back in other cases.

> Suggested names for the test:
> 
> extractHyperLinksForNonExistingLocalPathReturnsEmptyStringAsLocalPath

---------------------------^

Sorry I could not read beyond that point. Mind overflow :( Really too long :D

> As a rule of thumb, the vast majority of tests that test exactly one
> piece of behavior should contain only one assert statement.

This is different from practices I had with Java for a couple of years :)
In our Java projects we were encouraged to test for empty result, than for
array, than for its size, than for correctness of content. This decreased
number of test functions but tested all possible errors. The reason for
this is that with your approach we will have many functions that differ
only in one line. It does not look good for the code clarity or efficiency.

I understand your approach, it makes sense if completely different
assertions are being made. However if it is only about validating
non–essentials before essentials, I would prefer to keep my older Java
style because it saves time and size.

Thanks for your recommendations, they are definitely useful and will go
through them again to apply them to my development.

-- 
Dmitry Dulepov
TYPO3 expert / TYPO3 core&security teams member
Twitter: http://twitter.com/dmitryd
Read more @ http://dmitry-dulepov.com/




More information about the TYPO3-dev mailing list