[TYPO3-core] RFC #10220: Feature: Get some unit tests for the core

Oliver Klee typo3-german-02 at oliverklee.de
Tue Jan 27 17:35:50 CET 2009


Hi Ernesto,

Ernesto Baschny [cron IT] schrieb:
> I don't really see the need to have that much information in the test
> names function. If some test "failed", you will have to look at the test
> function anyway, to see what was wrong.
> 
> Even better is to document the test cases (phpdoc) so that one knows
> what is being tested. It is very ugly to have all information inside the
> difficult-to-read function name.

The point is to make the tests very fine-grained so that each test
checks for exactly *one* particular behavior of that class (or
function). (When developing test-first properly, this automatically
happens.)

So when one test is broken, you see exactly what part of the behavior
isn't correct anymore. So the "speaking" test names are most useful when
a test actually fails, and others don't fail. Without reading the code,
your then already can narrow down your search a lot.

Example:

testGetFooReturnsNonEmptyStringFromPostFoo
testGetFooReturnsEmptyStringIfFooIsNotInPost
Failed: testGetFooThrowsExceptionIfFooInPostIsTooLong

> And maybe split-up test cases in different classes, because I can
> imagine that testing "TCEmain" will be a LOT larger with time.

Yes, you're perfectly right. I'll split up the test classes into several
test cases when they get to big.

> t3lib_tcemain_accesscontrol_testcase:
>   testNonAdminCannotModifyAdminTable()
> 
> And instead of:
> 
> t3lib_tcemain_testcase:
> 
> testCheckModifyAccessListForNonAdminWithTableModifyAccessForContentTableReturnsTrue()
> 
> How about:
> 
> t3lib_tcemain_accesscontrol_testcase:
>   testNonAdminCanModifyAllowedTable()

I'll think about it.

Best regards,


Oliver


More information about the TYPO3-team-core mailing list