The concept of Cest's

[dynasource]

@DavertMik, I would like to discuss the concept of the Cests and how it should or should not be applied.

Questions to be answered:

• Is Cest to be extended?
• Why should one use Cest & not extend from PhpUnits Test?
• Is Cest naming handy with repect to lack of support by IDE (Netbeans does not support it so you cannot use nice functions like "run focused test method" etc.)

thanx

[Ragazzo]

Why should one use Cest & not extend from PhpUnits Test?

Cest were designed for UI testing to do some fixture load / unload and other things before and after scenario run. They have nothing in common with phpunit unit tests.

[austenc]

To elaborate on what @Ragazzo said, a Cept is more of a single testfile, without any class-based structure. A Cest offers a class-based approach to organizing your tests.

[DavertMik]

Is Cest to be extended?

Yes. That's why there is no baseclass of Cest, so you can extend it in way you want to.

Why should one use Cest & not extend from PhpUnits Test?

Because PHPUnit_Framework_TestCase is badly designed and have lots of methods you don't own, without a clear idea of their usage. Methods like: once, atMost, at are confusing. Especially strange to have method run in a testcase class.

Unlike PHPUnit_Framework_TestCase Cest file contains nothing more then tests itself. All support code is supposed to be moved out of it into helpers. Thus, using Cest makes code clearer and follows single responsibility principle.

Is Cest naming handy with repect to lack of support by IDE (Netbeans does not support it so you cannot use nice functions like "run focused test method" etc.)

I'm not quite sure of what IDE suport you need. I recommend to run tests from console...
Test names are taken from method names and can be redefined with $I->wantTo call

[dynasource]

@DavertMik, thanks.

I recommend to run tests from console...

That does not seem a optimal practice? You cannot instantly test a file with key strokes

[Ragazzo]

You cannot instantly test a file with key strokes

?

[dynasource]

ie. using a custom key in Netbeans (like F1, F2, etc)

[Ragazzo]

it is more matter of taste , i use Netbeans , however i run tests in console

[dynasource]

Don't you think its an advantage to be able to instantly test files / modules / applications by pressing 1 button?

Netbeans also renders the outputted XML

[Ragazzo]

is there something you want to suggest or what ?

[dynasource]

?

[austenc]

@dynasource - I use grunt to automatically run tests on save, saves me from having to press a key binding... I much prefer the console method to anything else as you can hook it up to your ide however you want. I don't think this is a codeception issue..

[Ragazzo]

@dynasource i mean you want to suggest something or what is the reason for this issue to be still open ?

[dynasource]

ahhh....ok.

My suggestion would be to be to stay as close as possible to PHPunit for maximal practical benefit, now but also in the future.

Most IDE's (will) have support for PHPunit, so using the same filename standard would improve the compatibility.

In case of Netbeans, it is compatible with *Test files, so Cests and Cepts are ignored.

IMHO, my suggestions would be:

• leave the current File naming. Its nice, but not practical for i.e. Netbeans
• leave the Cept principle instantly: its not OO (feels like going back to my early days in PHP) and the same can be done with Cests (doesnt really add benefits)
• rename Cests to Tests (and leave the extending to PHPunit TestCase up to the user).

[mdwheele]

Most IDEs honor the XML phpunit configurations for test suites. You can specify a suite pointed at a directory. The runner will traverse, looking for files with a specified arbitrary suffix.

http://phpunit.de/manual/current/en/phpunit-book.html#organizing-tests.xml-configuration

http://stackoverflow.com/a/7045887

In addition, I see nothing wrong with having both Cepts and Cests. They each serve their own purpose. Eliminating anything "instantly" is brash and irresponsible.

Nowhere does any best practice say test suites have to be OO. Tests are living documentation that assert that systems under test perform as expected according to thei feature set. That is all. The second point you make, in general, throws me off.

The naming convention in the third point is arbitrary and configurable. A better understanding of how your IDE executes tests might lead to a solution. Most IDEs allow for specification of a default test runner. In these cases you could point the IDE at that runner and do whatever you want there. Either way, IDE configuration is outside the scope of codecept ion documentation, in my opinion.

What may help more than anything is an exploratory blogpost describing different types of testing you can pull of with Cepts, Cests and Cests with Specify/Verify.