Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Showcase


Channel Catalog


Channel Description:

Codeception: BDD-style testing in PHP

older | 1 | .... | 6 | 7 | (Page 8) | 9 | 10 | .... | 12 | newer

    0 0
  • 10/29/12--18:03: ProTips in Managing UI
  • Hi, we've decided to start a pro tips post series on Codeception. We hadn't too much time recently, because of the work on our startup Bugira, and the release of community-driven catalog oj Javascript libraries - Jster. You should definitely visit Jster (and add it to bookmarks), as it contains more then 800 javascript libraries for any needs in frontend development. But finally, We can get back to Codeception and tell about it's best usage practices.

    Tip 1: Variables for UI elements

    You can write pretty complex tests using Codeception. When you have lots of them you may find that changing page UI elements can lead to refactoring all the tests. If you plan to develop a solid automation platform for your web application, consider putting all UI elements into the variables. In this case you can modify your tests pretty easy. If you see like you are creating too much tests, you should think on reorganizing them in a way that can act stable despite of changes in project. It's really hard, features, designs, can constantly change and affect tests. But it's possible to keep your tests stable if you use variables instead of raw values in tests.

    Let's say we have an acceptance test tests/acceptance/CreateTaskCept.php:

    <?php
    $I = new WebGuy($scenario);
    $I->wantTo('create todo task');
    $I->amOnPage('/tasks');
    $I->fillField('New Task','Update a blog');
    $I->click('Add');
    $I->see('Update a blog', '#tasks');
    ?>
    

    What if we change the name of buttons and the DOM position of the element where "Update a blog" text should appear? Let's move this elements to a _bootstrap file and push them into variables.

    In tests/acceptance/_bootstrap.php:

    <?php
    $task_add_button = 'Add';
    $task_new_field = 'New Task';
    $tasks_list = '#tasks';
    ?>
    

    And in tests/acceptance/CreateTaskCept.php:

    <?php
    $I = new WebGuy($scenario);
    $I->wantTo('create todo task');
    $I->amOnPage('/tasks');
    $I->fillField($task_fill_field,'Update a blog');
    $I->click($task_add_button);
    $I->see('Update a blog', $tasks_list);
    ?>
    

    As you see replacing values with variables shouldn't affect the test readability while you choose proper names for UI elements. We can also recommend to store user names, passwords, etc in bootstrap too. It will be automatically included on each test run. Use it.

    Tip 2: Use PageObject

    The PageObject is a pattern very popular among QA automation professionals. PageObject allows us to organize variables from a previous tip in more structured way. Instead of using raw variables we will group them into a class and use them in test and helpers. But classes and constants can't be added to _bootstrap, because bootstrap will be loaded before each test, so it will trigger an error: "Fatal: Cannot redeclare class". Let's deal with that by creating a new PHP file for TodoTask page class:

    In tests/acceptance/_todoTaskPage.php:

    <?php
    class TodoTaskPage {
        const URL = '/tasks';
    
        static $add_button = 'Add';
        static $new_field = 'New Task';
        static $list = '#tasks';   
    }
    ?>
    

    Let's add it to tests/acceptance/_bootstrap.php:

    <?php
    require_once '_todoTaskPage.php';
    ?>
    

    In this case you won't get lost in where which UI element is located. Because in PageObject pattern the UI element is bound to a page, which we defined by the URL property. And here is the updated test:

    <?php
    $I = new WebGuy($scenario);
    $I->wantTo('create todo task');
    $I->amOnPage(TodoTaskPage::URL);
    $I->fillField(TodoTaskPage::$new_field,'Update a blog');
    $I->click(TodoTaskPage::$add_button);
    $I->see('Update a blog', TodoTaskPage::$list);
    ?>
    

    After this update we have all the UI elements for todo task page kept in one place. Using and IDE you can easily find the right element and insert it into any test of your suite. Despite the raw variables classes and constants are accessible in helpers and unit tests. Also you can improve the page object classes with PHP's OOP power. If you are using PHP 5.4 you can include global UI elements (menus, breadcrumbs) with traits.

    Lets create a trait for menu component in tests/acceptance/_menu.php:

    <?php
    trait GlobalMenu {
        public static $global_menu = "//div[@id=menu]";
    
        public static function menuItem($index)
        {
            return self::$global_menu.'/ul/['.$index.']';
        }
    }
    ?>
    

    We add it to tests/acceptance/_bootstrap.php:

    <?php
    require_once '_menu.php';
    require_once '_todoTaskPage.php';
    ?>
    

    And we are using it in previously declared TodoTaskPage:

    <?php
    class TodoTaskPage {
    
        use GlobalMenu;
    
        const URL = '/tasks';
    
        static $add_button = 'Add';
        static $new_field = 'New Task';
        static $list = '#tasks';   
    }
    ?>
    

    And now we can use properties and methods of a trait included in class. Thus, TodoTaskPage, as any class that uses GlobalMenu trait can access a menu. Let's write a new test for checking that menu contains a button to create a task.

    <?php
    $I = new WebGuy($scenario);
    $I->wantTo('check task creation link is in a menu');
    $I->amOnPage(TodoTaskPage::URL);
    $I->see('Create Task', TodoTaskPage::menuItem(3));
    ?>
    

    If you think on layout components as a traits and pages as classes, you can reorganize your UI elements in a very flexible way. Changes in markup or texts won't affect a tests, as you can easily update all the tests that rely on that element. You can even teach your template developer to update the corresponding PageObject each time she changes template.

    Conclusion

    Codeception is simple, yet powerful tool for test automation. If you plan to use test automation for the enterprise level projects, it's better to start with proper organization. As we think on architecture before writing the first line of code, we should think on scalable architecture of tests platform. Using PageObject and variables can dramatically improve the reusability (and keep KISS and DRY principles) of your tests.


    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.


    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.


    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.


    0 0
  • 01/15/13--17:03: Codecepion 1.5.1
  • 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
    

    0 0
  • 01/20/13--17:03: Codecepion 1.5.2
  • 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
    

    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!


    0 0
  • 02/07/13--17:03: Codeception 1.5.3
  • 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
    

    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.


    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
    

    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.


    0 0
  • 03/09/13--17:03: Codeception 1.5.6
  • 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
    

    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.


    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.


    0 0
  • 02/17/14--17:03: Codeception 2.0 alpha
  • 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.


    0 0
  • 03/17/14--18:03: Codeception 2.0 beta
  • 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!


    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
    

    0 0
  • 04/04/14--18:03: Codeception 1.8.5
  • 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
    

    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" 
    

    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" 
    

older | 1 | .... | 6 | 7 | (Page 8) | 9 | 10 | .... | 12 | newer