Quantcast
Channel: Codeception
Viewing all 321 articles
Browse latest View live

Protips 2 - Extending Modules

$
0
0

Today, we will continue covering advanced topics on Codeception. The main power of Codeception is it's modules, there are already plenty of them, even though you might want to extend one of them. Let's say you are using Symfony2 and you want to add additional actions, you actually miss in current module, like dealing with FOSUserBundle: registering, authenticating, etc. You can create a helper and connect with Symfony2 module, get access to dependency injection container and do anything you need there. Sometimes you might want to change the module initialization scripts. This happens if your application configured in a custom way and module doesn't work properly because of it.

In both cases you might want to improve current Symfony2 (or any other module) implementation. That's pretty easy, because we can use just the simple OOP inheritance. You can create your own module Symfony2Helper and inherit it from default Symfony2 module. This module will act as a regular Helper, and should be placed to tests/_helpers dir.

In the next example we will redefine initialization for working with Symfony2 applications located in app/frontend path with Kernel class located in app.

<?php
class Symfony2Helper extends \Codeception\Module\Symfony2
{
    // overriding standard initialization
    public function _initialize() {
        // bootstrap
        require_once getcwd().'app/frontend/bootstrap.php.cache';
        // kernel class
        require_once  getcwd().'/FrontendKernel.php';

        $this->kernel = new FrontendKernel('test', true);
        $this->kernel->boot();

        $dispatcher = $this->kernel->getContainer()->get('event_dispatcher');
        $dispatcher->addListener('kernel.exception', function ($event) {
            throw $event->getException();
        });
    }    
}
?>

Please, refer to the _initialize method implementation to understand the default behavior. To get the idea whether you need to inherit and redeclare methods of module, you need to review it's code. If you see your requirements can't be met by using config options, please override.

By using inheriteance you can redeclare all the methods or initialization hooks you don't like. The API of parent module is pretty clean and even when you use the phar version of Codeception, you can read it's code on GitHub. If you stuck because Codeception module works improperly, you are free to fix that.

And yep, if your improved module is worth sharing with community, submit a patch and it will be added to official distribution. After all, that's how the Open Source works.

Thanks for reading. Use Codeception professionally.


Stop Simulating BDD, Write Tests

$
0
0

I keep receiving one question. Well, actually two: "What makes Codeception different comparing to Behat". And the next one: "Why can't I write Codeception tests in human language like Behat does". I think the time has come to answer this questions.

As you know, the Behat project is not only a tool but a methodology. The Behavior Driven Development concept requires that the User Stories to be written, and then executed as a test. Behat is a right tool for teams who strictly follow the BDD methodology. But what if you don't? For what in the world you need tests written in plain English?

If you write a story like this, using Behat and MinkContext for example,

Given I am on "/product/1"
When I click "Purchase"
And I fill in "name" with "Michael"
And I fill in "credit" with "321123123"
And I click "Order"
Then I should see "The product was purchased!"

you actually write test, and not a story. Because the feature you describe won't change If you rename field "credit" to "credit card", but the test will fail. You may change the text "The product was purchased" to "iPhone5 was purchased. Thank you!" and that will make test fail too. So you will rewrite the user story every time you change every detail that may affect passing test. In this case the manager who wrote this spec will debug and update user story to make the test pass.

And so your manager becomes tester. His role is now not only to deliver specifications to team but also to make this specifications written as tests and make them pass.

But what If you want one additional step to the scenario?

Given I am "/product/1"
When I click "Purchase"
Then I should see "1 product" in the bin

For this step see "1 product" in the bin you should write a custom step. If only your manager knew PHP for it! Ideally to become manager + tester + PHP guru. But no, manager needs to ask your developer to write the necessary step. Thus, already two people are writing the test. And one of them knows PHP. And when you will hire a QA will you require a knowledge of PHP? Well, yep. Thus because you don't want to disturb your PHP devs and assign them additional tasks.

When your product growths your tests becomes more and more complex. And you need to keep them updated for each change. When you use the plain English text, you don't have a control over tests. When your form don't have a label you need to write custom step instead of I fill in, because it's actually wrong to use CSS or XPath selectors inside a Behat feature. It's not plain English text anymore with CSS. You need PHP developers to create additional steps.

Why Codeception is better testing tool? Well, just because it is a testing tool at first. Spend a day, to teach your manager/tester/qa PHP DSL, install a Netbeans or PHPStorm (or any other IDE), and start writing tests. Even when tests looks similarly to Behat features they give more power and control over the process.

<?php
$I = new WebGuy($scenario);
$I->amOnPage('/product/1');
$I->click('Purchase');
$I->fillField('name', 'Michael');
$I->fillField('credit', '321123123');
$I->click('Order');
$I->see('The product was purchased!');

This test in the process of evolution can be transformed into something more complex. You can use CSS and XPath everywhere, so when you change the "Order" button with an image, you can use it's CSS and quickly update a test to make it pass. Also, you can move repeatable elements into variables and classes and make a test that looks like this:

<?php
$I = new WebGuy($scenario);
$I->amOnPage(ProductPage::URL);
$I->click('#purchase');
$I->fillField('name', $user_name);
$I->fillField('credit', $user_credit);
$I->click('img a#order');
$I->see(ProductPage::$successMessage);

Just the same scenario. Well it's a bit harder to read, as we added CSS selectors, but as you see this test pretty much more flexible. It can be easily refactored and improved without writing any custom method to helper.

Don't fall into a marketing trap. You will find yourself writing tests two times: as a feature in plain English and in code with PHP.

It's better to have one person who can take a full control over test automation then, delegate some tasks to developers, some tasks to managers. If you are developer and you work on your own project. Why PHP is not suitable for you? Why do you want to write code 2 times: once in feature with Gherkin and second time in Context. Is it KISS? Is it DRY? I don't think so.

Will Codeception support plain text test scenarios? Really, I thought on that. But I don't want to put the limits. Using plain text makes impossible to use variables, loops, grabbers, and thus use PageObject pattern. Which is very important for solid and concrete test automation platform.

Behat is great BDD tool and it's author @everzet also states: don't use it for functional testing. Choose the right tool for job.

Disclaimer: I'm not very good in theory, I'm very practical guy. I won't refer you to any published books or methodologies. But If you want an authority... Well, David Heinemeier Hansson (the creator of Rails) wrote in his blog: 1"Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests". And Behat is Cucumber for PHP. DHH is known for his dislike to popular BDD tools like RSpec or Cucumber. But he is very pragmatic and very scrupulous in testing.

Codeception released with CodeCoverage support

$
0
0

We'd like to announce new Codeception 1.5 major release. This time our improvements are CodeCoverage and Remote CodeCoverage added. These features allows you to collect code coverage reports for all your tests: unit, functional, and acceptance and merge them together. So now you can review what parts of your applications are tested and which are not even for Selenium and PhpBrowser tests which are executed on a webserver.

Read more in the new Guides chapter.

There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

code coverage

Thanks to tiger-seo for codecoverage feature. He did a great job developing a remote script c3.php which is a unique in it's way.

But back to Codeception. As you may've noticed our website is updated too. Documentation was improved, search was added, and nice Quickstart page added too. So if you didn't try Codeception yet, it's very easy to start now. In only 6 steps.

Modules

Two useful modules were introduced by judgedim. We have support of MongoDb and Redis now. They both can clean up your storages between tests and Mongo can perform checks in your collections. So If you are working with NoSQL databases, you should try them in your tests. If you use different NoSQL databases, please submit your patches, and they will be included in next release.

UX Improvements

Now you can execute a test by providing relative path to test, like.

php codecept.phar tests/acceptance/SignInCept.php

This small tweak imprioves user experience for *nix users as they can use autocompletion when running a test.

Also you can run test from one specific directory, i.e. match a group of tests:

php codecept.phar tests/acceptance/admin

Bugfixes

Composer package is works again. It's really hard to follow the stability in the world of constant changes, so we recommend use of phar for testing, just because it's prepackaged and always runs as expected. But if you use Composer it's easy to add Codeception to your vendors and receive all new updates with new release. Don't forget to mark @stable Codeception version.

Install

As usual, Codeception 1.5.0 can be downloaded from site,

installed via PEAR

$ pear install codeception/Codeception

or via Composer

$ php composer.phar update

Thanks

As you may've noticed all that guys who took part in developing Codeception are now shown on every page of this site. Thn this way we say thank for all our contributors and all guys who support this project, for all companies that adopt Codeception in their workflow.

Codecepion 1.5.1

$
0
0

You know, it's a common situation when just after the brand major release comes a small release with patches and bugfixes. Yeah, Codeception 1.5.1 has nothing to surprise you, still it's reommended to upgrade if you are running the phar vs composer issue. As we discovered with the help of alexshelkov, that Codeception packaged phar was trying to load PHP libraries from a local composer installation. So if you was trying phar version in project that already use composer, you may have seen strange errors.

This bug was fixed and last version 1.5.1, ready for download.

A simple improvement was introduced by DevMan. It allows you to execute Codeception from any directory if you set a path to config file with a -c parameter.

php codecept.phar run -c /var/myproject/codeception.yml

And finally we are back green on Travis. We had some issues with Travis infrastructure (not the tests), but we managed to solve them. Did you know that it takes 8 minutes to run all internal tests of Codeception? Yeah, we've got lots of tests )

Build Status

Update

Please redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

Codecepion 1.5.2

$
0
0

Yet another minor release. It introduces more compact form for unit tests.

<?php
use Codeception\Util\Stub;

class UserRepositoryTest extends Codeception\TestCase\Test
{
    protected function _before()
    {
        $this->user = new User();
    }

    public function testUserIsNotAdmin()
    {
        $this->assertFalse($user->isAdmin());
    }

}
?>

We moved all Codeception's setUp and tearDown routine into parrent class and left you more clean _before and _after methods for your preperations. They act just the same as setUp and tearDown for PHPUnit. So _before is executed before each test and _after after it. Tests should look more clean now. If your tests already have setUp and tearDown methods nothing is changed for them.

Accessing Modules in Unit Tests

Another nice feature for Symfony2 users and not only them. Form now on you can access a module from your unit test. This is done to access public properties of your module. For example, here is how you can retrieve a Symfony Dependency Injection Container:

<?php
protected function _before() 
{
    /**
   * @var $container Symfony\Component\DependencyInjection\Container
   */
    $container = $this->getModule('Symfony2')->container;
    $this->em = $container->get('doctrine');
}
?>

Also we'd like to announce the upcoming modules for Yii and Laravel frameworks.

In the meantime we will release more complete guides on How to integrate framework to Codeception.

Bugfixes

  • Composer build is finally is stable and doesn't require minimal-stability: dev. Thanks to: jacobkiers.
  • Adding support of pecl_http by phpcodemonkey.
  • Methods of Guy received documentation and examples (phar bug).
  • generate:cest command requires a tested class name no more.
  • PostgreSQL driver improved .

Update

redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

for composer version

$ php composer.phar update

or via PEAR:

$ pear install codeception/Codeception

Connecting PHP Frameworks. Part 1

$
0
0

As you know, Codeception has various modules for functional testing of PHP applications. Really, you could use Selenium, but as an advice, please leave Selenium for QAs.

As a developer you need to get more technical details for each test. If test fails you need to see the actual stack trace. As a developer you need to have all test running much faster. You can't wait for an hour before pushing your commit.

If you ever had tried Codeception with Symfony2 you should know how fast are functional tests. You should know how helpful is printed information from profiler: queries used, user authentication status, etc.

In case you want to try functional tests with your own framework you should develop module for it. Basically it's not that hard as you think it is. But some frameworks suit better for integrations and some need additional hooks. In this post I will concentrate on integrating one of the modern PHP frameworks that use HttpKernel Symfony Component.

There are Laravel 4 and Drupal 8 that adopted HttpKernel interface. And more frameworks to come...

So in case you want to integrate Laravel or Drupal, or you know that your framework uses HttpKernel, you should follow this guide.

If you are not aware of what HttpKernel class is, please follow Fabien Potencier's' series of posts Create your own framework... on top of the Symfony2 Components

Contributor's Notice

First of all, how do we treat the user contributions? In Codeception we have liberal politics for accepting pull requests. The only thing, we can't test your implementation, as we just don't have experience in this frameworks. So when you commit module please test your module, and prepare to be it's maintainer. So you will need to write proper documentation and provide support it. Answer to questions on GitHub, in Twitter, etc. Yep, this is opensource.

But we will help you with that. The more developers will use your framework the more contributions your module will receive. So try to encourage framework community to test your module, use it and improve.

When your module is complete it will be packaged with Codeception and it's reference will be published on this site. This is done to make Codeception with all it's modules work out of the box from one phar archive.

Technical Implementation

So you decided to create a module for Codeception that provides integration with HttpKernel. Hope you do!

Check how it is done for Symfony2

  1. We load and initialize HttpKernel class in _initialize method.
  2. Before each test we create a HttpKernel\Client class for this kernel in _before method
  3. We shut down client after each test in _after method.

Let's narrow it to example.

<?php
namespace Codeception\Module;
use Symfony\Component\HttpKernel\Client;

class MyFrameworkModule extends \Codeception\Util\Framework {

    public function _initialize()
    {
        // $app implements HttpKernelInterface
        $app = require_once \Codeception\Configuration::projectDir().'/app.php';
        $app->setEnvironment('test');
        $this->kernel = $app;
    }

    public function _before(\Codeception\TestCase $test)
    {
        $this->client = new Client($this->kernel);
        $this->client->followRedirects(true);
    }

    public function _after(\Codeception\TestCase $test)
    {
        $this->kernel->shutdown();       
    }
}
?>

And basically that's all you need for integration. The Client class has everything to simulate requests and parse responses. Every module that extends Codeception\Util\Framework class will have actions: click, see, fillField, defined and documented in Codeception\Util\FrameworkInterface. This actions will work in just the same manner as for other frameworks. And it's really cool, that testing client is not aware of framework it is testing. All methods and their behavior are just the same. So tests for Symfony2, Zend, or your newly integrated frameworks will look just the same.

Still you may want to add something special for your framework. Maybe some additional initialization steps, or new actions. Let's say a framework you integrate have methods to authenticate a user by name. Why not to use this ability and to make a short cut for logging in?

<?php
namespace Codeception\Module;
use Symfony\Component\EventDispatcher\EventDispatcher;
use Symfony\Component\HttpKernel\Client;

class MyFrameworkModule extends \Codeception\Util\Framework {

    public function _initialize()
    {
        // $app implements HttpKernelInterface
        $app = require_once Codeception\Configuration::projectDir().'/app.php';
        $app->setEnvironment('test');
        $this->kernel = $app;
    }

    public function amLoggedAs($username)
    {
        $this->kernel->getService('session')->authenticate($user);

        $role = $this->kernel->getService('session')->getRole();
        $permission = $$this->kernel->getService('session')->getPermissions();

        // let's display additional information
        $this->debugSection('Role', $role);
        $this->debugSection('Permissions', json_encode($permission));
    }
}
?>

So now we can write a test like this:

<?php
$I = new TestGuy($scenario);
$I->amLoggedAs('davert');
$I->amOnPage('/user/profile');
$I->see('Davert');
?>

As you see, framework integration allows us to access it's internals. Services, classes, configurations, etc. Please add methods that you think may be useful for other developers that will write functional tests. Also you can display some technical details with debug and debugSection methods.

Let other modules get access to framework internals too. In our case we can define kernel as public property and make it accessible from user helper classes.

<?php
class MyFrameworkModule extends \Codeception\Util\Framework {
    public $kernel;
}    
?>

In helper:

<?php 
class TestHelper extends Codeception\Module {

    public function doSomeTrickyStuff()
    {
        $kernel = $this->getModule('MyFrameworkModule')->kernel;
        $kernel->doTrickyStuff();
    }
}
?>

In case you want to provide flexibility you can add configurable parameters to your module. Let's update our example to use additional parameters.

<?php
class MyFrameworkModule extends \Codeception\Util\Framework {
    
    // paramter with default var
    protected $config = array('file_name' => 'app.php');

    // a parameter that we can't guess 
    protected $requiredFields = array('app_name');

    public function _initialize()
    {
        // $app implements HttpKernelInterface
        $app = require_once Codeception\Configuration::projectDir().$this->config['file_name'];
        $app->setEnvironment('test');
        $app->init($this->config['app_name']);
        $this->kernel = $app;
    }
}    
?>

Module won't start if app_name parameter is not set. But file_name parameter is optional and can be redefined.

In the end here how should look functional.suite.yml that includes your newly developed module:

class_name: TestGuy
modules:
  enabled: [MyFrameworkModule, TestHelper]
  config:
      MyFrameworkModule:
          app_name: blog

Keep in mind that main principles of all Codeception modules are simple and smart. This means, if you can guess some parameters - do not require them to be explicitly set.

Conclusion

It's pretty simple to integrate any framework if it's modern and built with Symfony Components. If you have various projects using this framework and you want to get it tested well, try to develop integration. It's not that hard: only 3 methods to implement. Share your work with others, and let it be added to main package.

We appreciate all contributions and all frameworks. Let's unite the PHP world!

Codeception 1.5.3

$
0
0

Urgent fix for Selenium2 module. It appeared that Selenium sessions were not restarting. The Travis-CI didn't reveal this problem. Selenium tests were passing as usual, just because there were no session related tasks. Main purpose for 1.5.3 was to release this fix. Some other fixes are also included, but it's the most important one.

Modules

In this release we also introduce very basic implementation of Yii module by Ragazzo. If you use Yii, please try it and help us improve Yii integration. To start using, please review the module documentation and issue description on Github.

Also we've got some improvements for AMQP module. Not only queues are cleaned up between tests, but also you can check if messages came to queue, grab them from queues, or publish new messages. This module was tested with RabbitMQ, but it should work with other AMQP providers too. This module is based on php-amqplib.

Generators

From now on you can generate classical PHPUnit tests, with no Codeception stuff in it. Just the plain old PHPUnit tests that you can run natively with PHPUnit itself. For this we have new command generate:phpunit

Use it as regular:

php codecept.phar generate:phpunit NewTest

Also generators now support namespaces. So when you type class name with namespaced, Codeception will generate directories (according to PSR-0) and will put namespace into your newly generated file.

Check out sample usages.

php codecept.phar generate:cest \\Entity\\User
php codecept.phar generate:test \\Entity\\User
php codecept.phar generate:phpunit unit \Entity\\User
php codecept.phar generate:phpunit unit "\Entity\User"

Update

redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

for composer version

$ php composer.phar update

Testing Symfony2 Apps with Codeception

$
0
0

From the beginning of it's existence Codeception was in good relations with Symfony2 framework. Codeception was built on Symfony Components and uses BrowserKit and HttpKernel components for launching functional tests. It's a shame we didn't have a complete Symfony2 integration tutorial before. But we will try to fill this gap today.

What benefits you get by using Codeception with Symfony2? Let's list all of them:

  • user-friendly syntax for functional tests
  • access to container in unit tests
  • testing REST and SOAP services built on Symfony
  • fastest data cleanup when using with Doctrine2

The installation is pretty simple. You can use Composer (as you are used to it), but we'd recommend to try phar package. In this case you can avoid unnecessary dependencies. But all this versions are equal. And when you installed Codeception and executed a bootstrap command you should configure your functional test suite.

In file tests/functional.suite.yml:

class_name: TestGuy
modules:
    enabled: [Symfony2, Doctrine2, TestHelper]

And nothing more. You just need to declare that you will be using Symfony2 and Doctrine2. The Symfony2 module will search for AppKrenel on initialization (in app) and use it for functional tests. Doctrine2 module will find that Symfony2 module is declared and will try to receive default database connection from container. Of course, If you use non-standard setup this behavior can be reconfigured.

Functional Testing

Let's create a first functional test. We use generate:cept functional TestName command.

<?php
$I = new TestGuy($scenario);
$I->wantTo('log in to site');
$I->amOnPage('/');
$I->click('Login');
$I->fillField('username', 'admin');
// ....
?>

And so on. Unlike standard Symfony2 tests you don't need to deal with filters, CSS, and XPaths. Well, you can use CSS or XPath in any selector, if you need to. But on start you can keep your test simple and compact.

The commands we use here are common for most modules that perform testing of web application. That means, that once you discover a need for Selenium, this test can be executed inside a web browser using Selenium2 module. But some commands are unique to Symfony2 module. For example, you can use seeEmailIsSent command that checks if application has submitted an email during the last request. Check Symfony2 module reference for all commands we provide.

Unit Testing

Codeception's unit tests are a bit improved PHPUnit's tests. Inside a unit tests you have access to initialized modules and guy classes.

<?php
class PaginateTest extends \Codeception\TestCase\Test
{
    private $serviceContainer;
    protected $codeGuy;

    protected function _before()
    {
        // accessing container
        $this->serviceContainer = $this->getModule('Symfony2')->container;
        $this->serviceContainer->enterScope('request');
    }

    public function testDefaults()
    {
        // using container
        $this->serviceContainer->set('request', new Request(), 'request');
        $paginate = new Paginate($this->getModule('Symfony2')->container);
        $this->assertEquals(1, $paginate->getCurrentPage());
        $this->assertEquals(0, $paginate->getCount());
        $this->assertEquals(20, $paginate->getLimit());

        // checking data in repository
        $this->codeGuy->seeInRepository('SettingsBundle:Settings', ['pager_limit' => 20]);
    }
}    
?>

If you want to bypass Codeception hooks for PHPUnit you can create a plain PHPUnit test with generate:phpunit command and get a traiditional PHPUnit's test. Then you can put this test into bundle.

Conclusion

Ok, you will probably ask: why is it better then Behat. We have a wide answer for that. A short is: Codeception is for testing, Behat is for Behavior Driven Development. If you need a professional testing tool that supports PageObject pattern, complex Locators, refactoring capabilities and CodeCoverage - Codeception is a good choice for that.

We say thanks to @everzet for wonderful Mink (that is used for acceptance tests) and to Sebastian Bergmann for it's PHPUnit. Codeception uses their powers, but makes them a bit simpler in use.


Codeception 1.5.4. Skip Tests, UTF fixes, etc.

$
0
0

Today we are releasing Codeception 1.5.4. This is minor bugfixing release consisting of GitHub issues. And a small yet awaitied feature introduced: ability to skip and mark Cepts as incomplete.

It's pretty simple, though.

<?php
$scenario->skip();

$I = new WebGuy($scenario);
$I->wanTo('do something, but I would rather not');
$I->amOnPage('/');
//.....
?>

This makes this test to be skipped. Similarly it can be marked as incomplete.

<?php
$scenario->incomplete();

$I = new WebGuy($scenario);
$I->wanTo('do something, but I would rather not');
$I->amOnPage('/');
//.....
?>

The skip and incomplete methods can take one argument, that descrines a reason why this tests were marked this way.

<?php
$scenario->skip('waiting for new markup');
$scenario->incomplete('welcome page appearence not tested');
?>

Bugfixes

Update

redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

for composer version

$ php composer.phar update

Codeception 1.5.5 and Roadmap Announced

$
0
0

Yes, here is a new version of Codception with more features and bugfixes in it. We have a flexible relase cycle, so the new version comes when we have a set of updates that you might be needed. We want to say "thank you" for all contributors, and for everyone who helps making Codeption better. It's always nice to get pull requests or follow discussions in our issues secition. So let us sum up the work was done during last 2 weeks and share it with you.

Use Codeception in Different Places

All codeception commands got -c option to provide a custom path to tests. The exception is bootstrap command. It accepts a custom directory as a second argument:

php codecept.phar bootstrap ~/mynewproject
php codecept.phar generate:cept acceptance Login -c ~/mynewproject
php codecept.phar generate:test unit MyFirstTest -c ~/mynewproject
php codecept.phar run -c ~/mynewproject
php codecept.phar generate:scenarios acceptance -c ~/mynewproject

Alternatively you may specify path to codeception.yml file in -c option: php codecept.phar run -c ~/mynewproject/codeception.yml

Thus, you don't need to keep your codecept.phar in the root of your project anymore. Use -c option and one local runner for all your projects.

Skipping Tests

Skipping and marking tests of incomplete was improved. We did a new solid implementation for it (it was very basic in 1.5.4). Now If a test is marked to skip, no modules will be touched.

<?php
$scenario->skip('this is not ready yet, move along');

$I = new WebGuy($scenario);
$I->wanTo('do something, but I would rather not');
$I->amOnPage('/');
//.....
?>

This feature required to rework some core classes (like Step and TestCase and Scenario) but hopefully we simplified our code.

Bugfixes

  • acceptPopup with Selenium 2 does not trigger Exception any more
  • error handling was improved to skip blocked with @ alerts, yet to throw ErrorException for notices, warnings, errors.
  • ZombieJS configuration was fixed. Now the url parameter is required to specify app's local url.
  • REST seeStatusCodeIs method works correctly with Symfony2 now.

Update

redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

for composer version

$ php composer.phar update

Roadmap

For the first time we will announce the roadmap for Codeception. Actually we need your opinion: what features you'd like to see in new releases, and what things can be postponed. The list below is not a precise plan, but just a list of features we have in mind:

  • Make a PageObject pattern first-class citizen in Codeception. Add generators and guides to use PageObjects (for acceptance tests).
  • Multiple sessions for tests execution (see discission on GitHub)
  • Silex, Laravel 4, Zend Framework 2, Drupal 8, Phalcon integrations. The key problem here: we can't do this on our own. We need a real users of these frameworks, to create integration and test it on their projects. We have reworked functional testing guide to help you with this. Also use GitHub or personal contacts if you want to make a module.
  • Scenario Unit Tests to be rethinked. We have 2 options here: dump scenario driven unit tests (or mark them as deprecated) or rework them. Actually we need your real opinion. Here is an example of what new Cests may look like. They will dramatically improve the way you work with mocks and stubs in PHP. But will you use it? Please, let us know what you think.

To summarize: we'd appreciate contributions, feedbacks and ideas for next releases.

Codeception 1.5.6

$
0
0

Codeption 1.5.6 released with varous fixes to Selenium2 module (popups, screenshots) an other bugfixes. We added a bunch of tests for Selenium2 and they are runnng on TravisCI. Also, Codeception is now compatble with Symony 2.2. And few features were intrduced.

Basic Fixtures

Very basic implementation of fixtures was added to Db and Mongo modules. Now you can write something like:

<?php
// for Db
$I->haveInDatabase('users', array('name' => 'davert'));
// for Mongo
$I->haveInCollection('users', array('name' => 'davert'));
?>

to add data for a test. For Db module, the inserted record will be cleaned up on text test, even If cleanup option is set to false. So haveInDatabase method cleans data after itself. Something similar exists for Doctrine2 module. Yet, it looks not like for Db and Mongo implementation:

<?php
$I->persistEntity(new \Entity\User, array('name' => 'Miles'));

Error Handling

From now on you can set custom error handling parameters per suite or globally.

class_name: WebGuy
modules:
    enabled: [PhpBrowser, WebHelper]
error_level: "E_ALL & ~E_STRICT & ~E_DEPRECATED"

Actually, E_ALL & ~E_STRICT & ~E_DEPRECATED is default error level for now. This may be changed in future.

Bugfixes

  • popups and modals in Selenium2 are fully tested and work correctly now
  • screenshots in Selenium2 module is saved correctly
  • seeInField method works correctly even if field is not in form
  • fix to AMQP module to push message to queue
  • Symfony 2.2 compatibility

Update

redownload your codeception.phar for update:

wget http://codeception.com/codecept.phar -O codecept.phar

for composer version

$ php composer.phar update

Headless Browser Testing with Selenium2 and PhantomJS

$
0
0

This is a guest blogpost by Jon Phipps. Jon explains how to use PhantomJS -- the most anticipated testing backend in Codeception.

If you're running acceptance tests in Codeception that require interaction with JavaScript, or have scripts that manipulate the DOM, the speedy Php Browser driver won't help you since it doesn't support JavaScript. The best options for running tests using JavaScript are the Selenium2 and ZombieJS drivers.

The Selenium2 driver actually loads and runs an active browser session, manipulating the browser just as a human would. ZombieJS is a 'headless' browser that provides all of the features of a regular browser, but without a display interface. Without the extra time spent waiting for the display to actually render, a headless browser like ZombieJS can run far faster than a normal browser, so you're tests will execute in as little as half the time. But ZombieJS requires installing Node.js and can be a little buggy, plus it has its own API (which has both pros and cons). The Selenium2 driver is well tested and implements a standard API -- the WebDriver Wire Protocol -- across all of the browsers it has drivers for.

Now there's a headless browser that includes a WebDriver Wire Protocol implementation -- PhantomJS. The latest version of PhantomJS is an easy to install, stand-alone binary that doesn't require installing Node.js or any other dependencies, and ships with its own 'Ghost Driver' for implementing the WebDriver Wire Protocol. Which means you can drive it using the Selenium2 driver in Codeception, and anything that you can test in Chrome, Firefox, Safari, or IE using Selenium2, you can now test in half the time using PhantomJS

Even though it's not needed to run the most recent PhantomJS, it's a good idea to have Selenium2 installed so you can test in other browsers. If you haven't installed Selenium2, you just need to follow the instructions on the Codeception web site for installing and running the Selenium2 driver. It's pretty simple, but totally optional.

To get started with PhantomJS, just download PhantomJS. The binary is setup and ready to use for Linux, Mac OSX, and Windows. Put it, or a symlink to it, somewhere in your path so you can launch it from anywhere.

You're done with installation!

Next, open up a new terminal window and launch PhantomJS, telling it to use the its built-in WebDriver extension to use the port Codeception is listening to (4444 is the default), and leave the window open:

$ phantomjs --webdriver=4444

You should see a response like this in your terminal:

PhantomJS is launching GhostDriver...
[INFO  - 2013-05-10T14:11:05.076Z] GhostDriver - Main - running on port 4444

Now just enable the Selenium2 driver in your acceptance.suite.yml file and use the browser setting browser: phantomjs (an example file is on the Selenium2 driver page). If you're changing modules then you should also run php codecept.phar build.

Check it out by doing a fresh Codeception run:

$ php codecept.phar run acceptance

Your tests should now run quietly and silently, and much faster.

You should see some output in your PhantomJS terminal window providing some useful feedback on this session's capabilities provisioning. This happens on every run (the output below are the defaults):

[INFO  - 2013-05-10T14:33:43.796Z] Session [9dbc5700-b97e-11e2-8dc9-976d2e8732bf] - 
CONSTRUCTOR - Desired Capabilities:{
  "browserName" : "PhantomJS",
  "version" : "9",
  "platform" : "ANY",
  "browserVersion" : "9",
  "browser" : "firefox",
  "name" : "Codeception Test",
  "deviceOrientation" : "portrait",
  "deviceType" : "tablet",
  "selenium-version" : "2.31.0"
}
[INFO  - 2013-05-10T14:33:43.796Z] Session [9dbc5700-b97e-11e2-8dc9-976d2e8732bf] - 
CONSTRUCTOR - Negotiated Capabilities: {
  "browserName" : "phantomjs",
  "version" : "1.9.0",
  "driverName" : "ghostdriver",
  "driverVersion" : "1.0.3",
  "platform" : "mac-10.7 (Lion)-32bit",
  "javascriptEnabled" : true,
  "takesScreenshot" : true,
  "handlesAlerts" : false,
  "databaseEnabled" : false,
  "locationContextEnabled" : false,
  "applicationCacheEnabled" : false,
  "browserConnectionEnabled" : false,
  "cssSelectorsEnabled" : true,
  "webStorageEnabled" : false,
  "rotatable" : false,
  "acceptSslCerts" : false,
  "nativeEvents" : true,
  "proxy" : {
    "proxyType" : "direct"
  }
}
[INFO  - 2013-05-10T14:33:43.796Z] SessionManagerReqHand - _postNewSessionCommand - 
New Session Created: 9dbc5700-b97e-11e2-8dc9-976d2e8732bf

You can adjust these capabilities in your acceptance.suite.yml file like so:

modules:
   enabled: [Selenium2]
   config:
      Selenium2:
         url: 'http://localhost/'
         browser: phantomjs
         capabilities:
             webStorageEnabled: true

I have no idea if capabilities from the larger list of Selenium DesiredCapabilities that are not on the list you see reported from the driver are enabled for PhantomJS.

Headless testing can be a bit of a challenge, since it's impossible to 'see' what failed. But in this case, Codeceptions default logging and screenshot capture on failure can be extremely helpful, since you can then actually see the state of the browser at the point of failure.

There's quite a bit more that you can do with PhantomJS. The CasperJS project makes good use of the PhantomJS API and if you already have NodeJS installed it's a quick and easy way to play with some of the PhantomJS capabilities. CapserJS, aside from requiring NodeJS, only drives PhantomJS. So its not a reasonable alternative to Codeception. Maybe at some point there will be a native Mink driver for the PhantomJS API which will more fully exploit it.

Happy testing.

Codeception 1.8.3: Laravel and Yii2 DB actions

$
0
0

Here goes another minor release with some fixes and improvements. Codeception 1.8 now supports Laravel 4.1 and Yii2 and is tested for this frameworks on Travis. Also Laravel and Yii modules got some nice new actions for database interactions.

Laravel, Yii2, and Phalcon frameworks implement ActiveRecord pattern. That's why all database actions in this modules look and work in a very similar manner.

Laravel 4.1

<?php
$user_id = $I->haveRecord('users', array('name' => 'Davert'));
$I->seeRecord('users', array('name' => 'davert'));
$I->dontSeeRecord('users', array('name' => 'davert'));
$user = $I->grabRecord('users', array('name' => 'davert'));
?>

This methods will work for Laravel 4 as well, but Laravel 4.1 supports nested transactions and allows us to wrap functional test into one database transaction. This is really useful, as we can rollback any database changes we do in functional tests. Tests also run really fast, as nothing is written in database. A new cleanup config option was introduced to Laravel4 module, and by default it is turned on.

Now it is really simple to use database in your functional tests. Don't hesitate and try *Record methods in action!

Also nice seeSessionErrorMessage was added by elijan to perform validation error assertions.

Yii2

Yii2 is in very active development, and its official basic application is tested with Codeception, and uses Specify and Verify libraries. Yii2 module is tested on Travis as in official Yii2 repo and in Codeception repo as well.

<?php
$user_id = $I->haveRecord('app\model\users', array('name' => 'Davert'));
$I->seeRecord('app\model\users', array('name' => 'davert'));
$I->dontSeeRecord('app\model\users', array('name' => 'davert'));
$user = $I->grabRecord('app\model\users', array('name' => 'davert'));
?>

ActiveRecord methods work in very similar manner. We expect that Yii2 will have nested transactions support before the release.

Thanks to Ragazzo for Yii2 module contributions and bughunting.

Bugfixes

  • CodeCoverage was improved. Remote codecoverage with WebDriver or PhpBrowser opens page, sends authorization cookie before the test.
  • WebDriver cookies (and sessions) are destroyed after the test. If you have troubles when session is not restared in WebDriver - toggle restart option.

Update

redownload your codeception.phar for update:

1.8.3

php codecept.phar self-update

for composer version

$ php composer.phar update codeception/codeception

P.S. Yeah, yeah, Codeception 2.0 is on its way.

Codeception 2.0 alpha

$
0
0

Finally we are ready to show you Codeception 2.0. We tried not to break everything (as it was supposed for major version change), but keep things work as they are, but maybe in a different way. Let's review the most important changes:

Codeception: Not Just For Guys

Before 2.0 there were only Guys in it. That is not fair! We wanted to make Codeception a tool for everyone: for guys, girls, developers, test engineers, ninjas and even wookiees... (nope, wookiees should wait for 3.0).

That's why you can now choose the desired actor from a list during the bootstrap process.

Before proceed you can choose default actor:

$I = new [ACTOR]
  Select an actor. Default: Guy  
  [0] Guy
  [1] Girl
  [2] Person
  [3] Engineer
  [4] Ninja
  [5] Dev

so you all your test actors (that's how we call guy classes now) will be in form like TestGirl, WebNinja, CodeDev, etc. Pretty flexible.

Codeception: Not Alone

Before Codeception 2.0 guys (or should we say actors now) were left to themselves. You know, it is so sad to see that there is only $I in the test, forever alone, like on a desert island, or in space... But in 2.0 you can invite some friends into your tests. Let's say...

<?php
$I = new WebGuy($scenario);
$nick = $I->haveFriend('nick');
?>

So we can write multi-session tests that can be executed in two browser windows. You may try to run this test on github.com to see how it works:

<?php
$I = new WebGuy($scenario);
$I->wantTo('surf Github with Nick');
$I->amOnPage('/');
$I->submitForm('#top_search_form', array('q' => 'php-webdriver'));
$nick = $I->haveFriend('nick');
$nick->does(function(WebGuy $I) {
    $I->amOnPage('/Codeception/Codeception');
    $I->click('Issues');
    $I->canSeeInTitle('Issues');
});
$I->click('li.public:nth-child(1) > h3:nth-child(3) > a:nth-child(1) > em:nth-child(2)');
$I->seeInTitle("php-webdriver");
$nick->does(function(WebGuy $I) {
    $I->click('Milestones');
    $I->canSeeInTitle('Milestones');
});
$I->seeCurrentUrlEquals('/facebook/php-webdriver');
$I->click('Issues');
$I->canSeeInTitle('Issues');
?>

As you see, everything in does closure is executed in separate session. This way you can test user-to-user interactions on your site. For example Alice writes a private message to Bob and Bob responds back. Similarly you can have multiple REST sessions in a test.

Such scenario cases can be implemented. That's what friends are for.

Notable Changes

As it was announced earlier, the main goals for Codeception 2.0 was internal refactoring.

  • Mink (and its drivers) was removed completely. Instead you can use WebDriver module to do Selenium testing, and PhpBrowser (which uses Goutte) for browser-emulation. PhpBrowser module is now more compatible with frameworks modules, they use the same methods and acts in the same manner. If you were using Selenium or Selenium2 module you should switch to WebDriver, for PHPBrowser everything should (crossing fingers) work smoothly.
  • 2-phases test execution with tricky magic including usage of Maybe class was removed. Tests are now executed one time, like any regular PHP file. So you can use any PHP code in your tests, and appearance of Maybe object would not confuse you anymore.
<?php
$card = $I->grabTextFrom('#credit_card')
var_dump($card); // was showing `Maybe` instead of real value
?>
  • Codeception 2.0 require PHP 5.4 and higher. Time changes, PHP 5.3 is getting harder and harder to support, thus we decided to move to 5.4 and keep our code base up to date. And yes, we wanted to use short array syntax. We are tired to keeping write all those nasty array() stuff.
  • Actor classes (initial Guy classes) are now rebuilt automatically. Thus, you want get exception when change suite configuration, or add methods to helper. Rebuilds are not required anymore.
  • Added Assert module that can be used to write common asserts in your tests. You can now use seeEquals, seeContains and other actions inside your Cepts or Cests.
  • Experimental: added Silex module. We need your Feedback on using it.

Minor Internal Changes

Refactoring, Refactoring, Refactoring. We use PSR-2 now. We rewrote CodeCoverage. We have better directory structure... More new files. What else? Oh, lets admit it, these are not the changes you would actually notice. But internals are now more clean and easy to understand (Except the parts which heavily rely on PHPUnit).

Upgrading

We'd like to ask you to try Codeception 2.0 on your projects. Before the release is ready we need to collect feedback and fix all encountered issues. You know where GitHub issues are.

Download:

wget http://codeception.com/releases/2.0.0-alpha/codecept.phar

Via Composer:

composer require --dev "codeception/codeception:2.0.0-alpha"

Development of 2.0 now happens in master branch, so keep track on changes and send your pull requests.

Some Upgrading Notes

  • Run build command
  • Replace Selenium2 to WebDriver module
  • Check you don't use PHPBrowser->session property anywhere (it was Mink part)
  • CodeCoverage with c3 will require new version of c3.

What's next?

We need your feedback, and meanwhile we will work on updating documentation parts. 1.8.x will be maintained, but new features will be added to 2.x branch.

Codeception 2.0 beta

$
0
0

It took about a month to get to the beta release. This release brings lots of changes even a few BC breaks and clearly shows what Codeception 2.0 is planning to be. Today we will announce more technical changes, and not conceptual ones. As it was stated previously: Codeception 2.0 will bring lots of small improvements, will be much easier to extend, and understand. Changes for beta release were not planned initially, but were added to help Codeception evolve during the 2.0 branch development. Let's list briefly all major changes and see how to deal with them. Documentation for 2.0 branch can be found on GitHub and will be published on RC release.

Changes

  • Upgraded to PHPUnit 4.0
  • Upgraded to facebook/webdriver 0.4
  • RunFailed extension added. To rerun tests on fail include Codeception\Platform\RunFailed extension, and call codecept run -g failed.
  • Logger disabled by default and moved to Extension. You will need to install Monolog by yourself, and enable Codeception\Platform\Logger as extension.
  • Methods _before/_after of Cest can use $I object.
  • Destination for xml/html/reports can be customized. For instance
codecept run --xml myreport.xml
codecept run --xml /home/davert/report.xml
codecept run -g database --xml database.xml
```
  • --coverage + --xml or --html won't produce xml or html codecoverage output. Use new options coverage-xml and coverage-html instead. They were added so you could specify custom destination for codecoverage reports as well.
  • you can get current environment in a test by accessing $this->env (even in Cept)
  • shortcut functions added: codecept_debug to print custom output in debug mode, codecept_root_dir, codecept_log_dir, codecept_data_dir for retrieving Codeception paths.
  • extensions can change global config before processing.

Breaking Changes

In Codeception 1.x bootstrap files were used differently for different types of tests. They were introduced to pass variables (and fixtures) into Cept scenarios. They were almost useless in Cests, and absolutely useless for Test files. They are not removed at all, but now they are loaded only once before the suite. If you were using bootstrap files for setting fixtures, you still can use them, but you will need to require them manually.

<?php
require __DIR__ . '/_bootstrap.php'

$I = new WebGuy($scenario);
?>

The same way you can load bootstrap files into Cests. But we recommend to create _fixtures.php file, and use bootstrap file for suite initialization.

Dynamic Groups

One significant internal feature is dynamic groups. You can save test names into file and run them inside a group. That's how the RunFailed extension works: it saves names of failed tests into file tests/_log/failed, then execute codecept run -g failed to run these tests.

groups:
  # add 2 tests to db group
  db: [tests/unit/PersistTest.php, tests/unit/DataTest.php]

  # add list of tests to slow group
  slow: tests/_log/slow

For example, you can create the list of the most slow tests, and run them inside their own group. Pretty interesting and powerful feature that also can be used to run tests in parallel.

Parallel Test Execution

Not yet! Codeception does not support parallel test execution, nor will be provide it out of the box. That's because there is no solution that will fit for everyone. You may want to run parallel tests locally in threads via pthreads extension, or run them on different hosts via SSH, AMQP, etc. But we already have everything to implement parallel testing.

Here is the algorithm:

  • split all tests into groups (with dynamic groups)
  • run each groups separately
  • merge results

And we will write guides on implementing this algorithm, as well as we plan to release a sample tool that will run tests in parallel.

Try it

As usual, we need your feedback to get 2.0 released as stable.

Download:

wget http://codeception.com/releases/2.0.0-beta/codecept.phar

Via Composer:

composer require --dev "codeception/codeception:2.0.0-beta"

P.S. Our sponsors 2Amigos updated their site and logo. Check it out!


Codeception 1.8.4 with minor fixes

$
0
0

Bugfix release on stable 1.8 branch. While you are waiting for 2.0 RC and final version, you can update your current Codeception to get the newest patches and updates. Here they are:

  • [WebDriver] Correctly return to main page when switchToIFrame() is called by n8whnp.
  • [WebDriver] fixed screenshot capture by FnTm.
  • [Frameworks] More details in debug output by Ragazzo.
  • Fixed problem with encoding in $I->wantTo() by vgoodvin.
  • Add clone and unset capabilites to Maybe by brutuscat.
  • [WebDriver] Fixes to submitForm when typing password by pcairns.
  • [Phalcon1] haveRecord return id even when id is not public by xavier-rodet.
  • Modules to be loaded from global context by Ragazzo. Now you can pass long name of module into module configuration:
class_name: WebGuy
modules:
    enabled: [\My\Custom\Module, WebHelper]

Really helpful feature if you have multiple Codeception inits in one project and you want to have shared module.

All those features were included in 2.0-beta. Thanks to all contributors!

Update

redownload your codeception.phar for update:

1.8.4

php codecept.phar self-update

for composer version

$ php composer.phar update codeception/codeception

Codeception 1.8.5

$
0
0

New improvements and bugfixes came during the last month into the 1.8 branch. We summarized them all and prepared a new release.

Ecosystem

But before we proceed you should check out the new Addons section on this site. We had only extensions listed there, but now you can find new modules and even applications there. And let's name at least two projects you should definitely be aware of:

Thank you for all extensions and modules developers. If you developed a module, helper, or extension, share your work with others by adding your project to addons page (click Edit link in the bottom).

Bugfixes

  • [WebDriver] facebook/webdriver version was set strictly to 0.3. And this won't be changed in future for 1.8 branch. We accidentaly commited ~0.3 into the 1.8.4 which made composer to install 0.4 version of facebook/webdriver. There was API break in 0.4, so WebDriver module didn't work properly.
  • [Phalcon] Phalcon 1.3 compatibility added #944
  • [Laravel] Service providers are now correcly loaded by ShawnMcCool.
  • [Laravel] findRecord fixed by andkom.
  • [ZF2] Fixed handling of query parameters by piccagliani.
  • [Frameworks] Fixed problem with submitting form with input[type=image] by piccagliani.

Features

  • [Webdriver][Frameworks] input field can now be located by its name.
  • [Webdriver][Frameworks] element can be clicked by name too.

Update

redownload your codeception.phar for update:

1.8.5

php codecept.phar self-update

for composer version

$ php composer.phar update codeception/codeception

Codeception 2.0 RC: Strict Locators

$
0
0

Codeception 2.0 is almost ready for final release. Thanks for everyone who already running alpha/beta version of Codeception and provides us with valuable feedback. If everything goes well the final release will be published in a week. The delay between releases is dictated by the need to allow parallel tests execution. As it was said before: Codeception won't provide parallel test running out of the box, yet we will add a new chapter into guides where you will learn how to implement parallelism model that matches needs of your project.

Improvements

Strict Locators

In order to provide better element locations you can now specify locators explicitly like this: ['css' => 'input.name']. This will work for PHPBrowser, Frameworks modules, and WebDriver.

<?php
$I->fillField(['css' => 'input.name'], 'jon');
$I->click(['link' => 'Submit']);
$I->seeElement(['xpath' => './/div[@data-name="jon"]']);
?>

Allowed locator mechanisms are:

  • id
  • name
  • css
  • xpath
  • link
  • class

You can use strict locators in your Page Object classes as well.

See Element with Attributes

To improve checking element with expected attributes seeElement now takes second parameter:

<?php
$I->amOnPage('/form/field');
$I->seeElement('input[name=login]');
$I->seeElement('input', ['name' => 'login']); // same as above
?>

dontSeeElement works in corresponding manner.

grabAttributeFrom method added

To fetch value of attribute of element:

<?php
$I->amOnPage('/search');
$attr = $I->grabAttributeFrom('form', 'method');
$attr == 'GET'
?>

Also makeScreenshot method of WebDriver was simplified. Filename of saved screenshot does not include a test name.

Try it

Download:

wget http://codeception.com/releases/2.0.0-RC/codecept.phar

Via Composer:

composer require --dev "codeception/codeception:2.0.0-RC"

Codeception 2.0 RC2: Guzzle 4

$
0
0

Unfortunately this is not a final release of Codeception 2.0 you may have expected. Still we had to get another release candidate in order to implement one breaking and important change: upgrade to Guzzle version 4.

As you know PHPBroswer of Codeception used Mink, Goutte, and Guzzle to emulate visiting pages, filling forms, and other user-like web interaction. Recently Guzzle got a new major release, so we had to upgrade Codeception as well. We also removed Mink and Goutte and Codeception uses Guzzle directly. This will allow us faster to hunt down and fix the issues which may appear in future.

Guzzle changed their package name and namespace in latest release. If you were using Guzzle 3 and you want to upgrade to Codeception 2 you won't get any conflicts in dependencies. But if you were using Guzzle\Http\Client class in your tests or helpers you will to change it to GuzzleHttp\Client.

PHPBrowser additional configuration

Guzzle4 got very flexible configuration. You may omit CURL_ constants and use request parameters to set headers, auth, cookies, and SSL verification. Codeception now accepts all request parameters of Guzzle in module configuration part:

modules:
   enabled: [PhpBrowser]
   config:
      PhpBrowser:
         url: 'http://localhost'
         auth: ['admin', '123345]
         headers:
            'User-Agent': 'Codeception'
            Accept: 'application/json'
         curl:
             CURLOPT_RETURNTRANSFER: true

And yes, curl configuration section is left for more advanced options and for backwards compatibility. BTW, SSL settings should be also defined via new configuration using verify, cert, ssl_key request options.

Try it

As usual we need your feedback. Guzzle upgrade is very dramatic change and we recommend to try it on your test suites. If you have issues report them and we will try to fix them before the final release, which is schenduled for next week.

Download:

wget http://codeception.com/releases/2.0.0-RC2/codecept.phar

Via Composer:

composer require --dev "codeception/codeception:2.0.0-RC2"

Codeception 2.0 Final

$
0
0

Codeception 2.0 is out. It was a long journey to get here but it was worth it. Main purpose of making Codeception 2.0 was not to break things up. Instead we focused on making Codeception simpler in use and reduce that awkward WTF moments you were experiencing rebuilding Guy classes and discovering dark magic of Maybe object.

That's it. Codeception does not have 2-phases of execution and runs your tests as native PHP scenarios. It also does not require you to rebuild actor classes on configuration change - it is done automatically. And at last we don't have Guys anymore. They were renamed in more neutral Tester objects. But it is up to you how will you call your actors: Testers, Guys, or even ninjas, those names can be configured!

Naming Conventions

We decided to change some naming conventions in Codeception.

  • _log directory was renamed to _output. It was logical decision, as Codeception does not print any logs by default, but constantly uses _log directory for printing debug information and reports.
  • _helpers was renamed to _support. Now it is more obvious that this directory may contain not only helpers but any kind of support code required for tests.

As it was said, Guys were renamed to Testers. Actor classes and helpers are named by suite. For instance, acceptance test will start with this line:

<?php
$I = new AcceptanceTester($scenario);
// and uses AcceptanceHelper
?>

In unit tests we simplified access to actor classes by just using $this->tester property (actor title). Looks a bit more readable.

<?php
function testSavingUser()
{
    $user = new User();
    $user->setName('Miles Davis');
    $user->save();
    $this->tester->seeInDatabase('users',array('name' => 'Miles', 'surname' => 'Davis'));
}
?>

If you are upgrading from 1.x you can still use codeGuy as it was left for compatibility.

Listed naming changes are recommended defaults. You don't need to follow them if you plan to upgrade from 1.x.

Changes

Let's briefly name some important changes added in Codeception 2.0

  • PHP >= 5.4
  • Upgraded to PHPUnit 4.x
  • Upgraded to Guzzle 4.x
  • Removed Mink (and Selenium, Selenium2, ZombieJS modules)
  • Removed Goutte
  • Logger moved to extension and disabled by default
  • Naming conventions changed
  • One-time execution for all tests
  • Autorebuild of actor classes
  • MultiSession testing with Friends
  • Strict Locators introduced
  • Fail fast option -f added to run command
  • Coverage options changed behavior in run command
  • Bootstrap test are loaded suite, not before each test
  • Parallel Execution (!!!)

Guides

Guides were reviewed and updated for 2.0 release. Unit Testing guide was completely rewritten, and new chapter Parallel Execution was added. Please note that parallel running tests is advanced feature and will require some time for you for set everything up correctly. But If your tests run longer then 30 minutes, you will get a real benefit out of it.

The Most Important Bug Fixed

The Most Important Bug was reported by many of our users:

We decided to fix it for 2.0 release. Now the date in footer is displayed correctly according to PHP rules (using <?=).

Upgrading

Codeception 2.0 was publishing pre-releases since February. Lots of developers already gave it a try and reported their issues. We hope the upgrade will go smoothly for you. Basically what you need is to:

  • run build command
  • remove any internal usage of Mink or Goutte
  • remove any usage of $scenario->prepare() as it always return false now
  • optionally remove $scenario->running() calls and $I->execute calls. They are not required anymore.
  • take a look into PhpBrowser module which is uses Guzzle4 directly. You may have issues with using it (as it was completely rewritten). Please report those issues to GitHub.
  • Selenium2 module should be replaced with WebDriver (as you already didn't do so).
  • if you use variables in _bootstrap.php, rename it to _fixtures.php and load it manually into your tests.

If you have issues during upgrade send issues to GitHub and we will make upgrade more smoother.

wget http://codeception.com/codecept.phar

Via Composer:

composer require --dev "codeception/codeception:2.0.0"

P.S. Codeception 1.8.6 was released as well. List of its changes will go tomorrow.

Viewing all 321 articles
Browse latest View live


Latest Images