add codeception about yiiboilerplate HOT 8 CLOSED

Well, Codeception does not support the Gherkin syntax so Behat was chosen by default. Also, to setup Behat+Mink over Selenium is a great pain so it's better to have more complex setup already done in boilerplate code instead of less complex one.

That was the reasons. To avoid confusion as a maintainer of this stuff I'll not add Codeception to this boilerplate. Default test harness proposed to you by YiiBoilerplate is Behat and PHPUnit.

Nothing stops you from removing Behat harness from your setup and installing Codeception instead. To add Codeception only thing you need is to add a line "codeception/codeception:*" to your requirements anyway.

from yiiboilerplate.

just interesting...will you review your own decision after Yii2 release? Because Codeception will be packed by default :)

from yiiboilerplate.

Problem which YiiBoilerplate solved for Yii 1.x, does not exist in Yii2, because they already have the advanced application template, with separated frontend, backend and console entry points.

Only thing which is not there is the Vagrant harness and Phing build file. So for Yii2 maybe only thing worth using is the static code analysis and documentation harness from YiiBoilerplate, which can be moved to separate project.

Of course as Codeception has extensive support in Yii2 it's the test framework of choice there. However, nothing beats Gherkin syntax. Camel-cased test suites in Codeception are just ugly.

from yiiboilerplate.

However, nothing beats Gherkin syntax.

you are wrong. Gherkin is good enough when you are using BDD stories for specifiyng main app. rules and domain specifications. However writing a lot of scenarious are very painful in it, when you need to test all web-pages, its not his main purpose. You always face with mistyping. You also faced with problem that you cant have same sentence for different feature methods (they are matched via regexp), so you cant use more or less alike sentences to describe different features, because you are extended from main behat feature.

Camel-cased test suites in Codeception are just ugly.

suites are not camel case. Codeception has autocomplete support and very flexible and easy to extend because it is written in php and has no layer like gherkin.

Not to start holywar ofcourse, just as a note, because your opinion is not right at all and has nothing in common with reality.

from yiiboilerplate.

Man, it's not even a holywar.

camelCase is ugly by definition. We don't write like that in any real-world language. So anything beats it, especially Gherkin.

Any problem you can have with Gherkin is the problem with parsing natural language. You are expected to have decent domain model using ubiquitous language describing it to not end up with boatload of hacks in the FeatureContext supporting corner cases.

Mistyping is not a problem at all given that you have a regular domain vocabulary set up for your project.

Also, of course it's complete insanity to write all tests in Gherkin. It should be only the end-to-end acceptance tests, explaining the user-level features of the web app. There's no point in wrapping all tests in the Gherkin specs, because you'll end up maintaining some sort of AI for reading human descriptions of your tests.

Everything below the acceptance level tests should be in xUnit framework, to maintain the ability of tests to communicate the examples of usage of internal interfaces.

I am not the fan of Gherkin myself, because of the additional layer of natural language processing, and all of burdens related to it like maintaining lexical context and whatnot. However, I immediately see the very important benefit of the end-to-end acceptance tests written in regular subset of some natural language: you can use them as a method to communicate the domain model with your customer. Also, you can hand them to your QA team so they'll be able to understand what features you auto-test and what features they should test manually.

I don't understand your remark about "suites are not camel case". Here's real-world example of end-to-end test written in Codeception:

<?php
$I = new \WebGuy\CRMOperatorSteps($scenario);
$I->wantTo('add two different customers to database');

$I->amInAddCustomerUi();
$first_customer = $I->imagineCustomer();
$I->fillCustomerDataForm($first_customer);
$I->submitCustomerDataForm();

$I->seeIAmInListCustomersUi();

$I->amInAddCustomerUi();
$second_customer = $I->imagineCustomer();
$I->fillCustomerDataForm($second_customer);
$I->submitCustomerDataForm();

$I->seeIAmInListCustomersUi();

$I = new \WebGuy\CRMUserSteps($scenario);
$I->wantTo('query the customer info using his phone number');

$I->amInQueryCustomerUi();
$I->fillInPhoneFieldWithDataFrom($first_customer);
$I->clickSearchButton();

$I->seeIAmInListCustomersUi();
$I->seeCustomerInList($first_customer);
$I->dontSeeCustomerInList($second_customer);

This text fits my concept of "ugly" completely. I cannot just hand this text to my customer for sure. In Gherkin it would say exactly the same, but without the noise of PHP syntax. Also, to make the above test so readable I needed to make two support classes with the same amount of lines of code each.

So, I ended up essentially with the same setup as with Behat (top-level spec with supporting class implementing the human-readable methods), but without the benefit of readability provided by Gherkin syntax.

Maybe now you finally get my opinion of Codeception. I repeat, I dislike the Behat for the sheer amount of setup needed for it.

from yiiboilerplate.

camelCase is ugly by definition.

why are using Yii then?

Mistyping is not a problem at all given that you have a regular domain vocabulary set up for your project.
....in regular subset of some natural language: you can use them as a method to communicate the domain model with your customer.

i see you maybe know some of DDD/BDD things but if you saing that in your application all specifications and business rules are only about UI and you tests with mink+behat, so i will laugh :D The real thing here is that it is (your tests here) only UI testing and usually has nothing with business rules and specs of the domain model of project you are working on, until you are not building your software starting from UI, that is bad. You also should know that BDD/DDD is not about tools, so it is not cucumber/behat/etc, it is only about communication and crafting domain model with this communications by using ubiquitous language (DDD). Writing tests for UI with behat and screaming that you are doing BDD/DDD just is not right, and make me laugh))

This text fits my concept of "ugly" completely. I cannot just hand this text to my customer for sure.

Codeception output is the same as in behat+mink, usually customers only look in output.

Maybe now you finally get my opinion of Codeception. I repeat, I dislike the Behat for the sheer amount of setup needed for it.

yeah, i got it, you want to say that you are doing BDD/DDD by testing UI with behat+mink, unfortunately it is not so.

from yiiboilerplate.

Well, it's just easier for me to give up here. It seems I fail to explain my point in a way you are able to comprehend. More than that, you even began evaluating my experience and making some conclusions from it out of blue. So I just stop casting pearls here.

To the topic of this issue: in YiiBoilerplate by default a Behat+PHPUnit setup is configured. As YiiBolierplate is just a starting point of your application to use Codeception one just need to remove Behat+PHPUnit and add one line into the composer.json, requiring Codeception. Not a problem at all. No reason to put this one line into the composer.json by default, too.

For Yii 2 this project as a whole is unnecessary anymore, so the problem doesn't exist there either. Yii 2 expects you to use Codeception, so just do it.

from yiiboilerplate.

Yeah, no problem, was not thinking to offense you, sorry.

For Yii 2 this project as a whole is unnecessary anymore, so the problem doesn't exist there either. Yii 2 expects you to use Codeception, so just do it.

thats true, so will not offtop here no more)

from yiiboilerplate.