Skip Navigation LinksHome > Categories > Code from a Category

Automated testing using the Zend Framework

User Name: serfcompany
Name: Serf
Contact Me:
Home Page:
php,mysql,javascript,html,css. Preferable working with Zend Framework. Good know javascript. I worked with various, javascript frameworks such as(jquery, YUI3, extjs, sencha touch). [More]
Viewed Times: 2753
Add Date: 07/04/2012
In this article, given all the basic information that you need to write automated tests for applications, Zend Framework. Automated testing your web application is an important step for confidence in the quality and the absence of deterioration, when you make changes to your application.

Automated testing your web application is an important step for confidence in the quality and the absence of deterioration, when you make changes to your application.

With the testing framework of the Zend Framework (built with PHPUnit) you can make blocks of test cases for your Web applications without any prepirany.

Now, let's get down to business In the example I'll use the actual controller is one of my projects. This controller manages the activities related to accounts, such as entrance, exit, the registration and confirmation. We will use the test database with a scheme to clone our production database, with the Doctrine to control ORM (sorry, Zend_Db: () I assume that you are using the above scheme projects Zend Framework (1.6 +), and that you are familiar with Zend_Config and use the plug-in controller Initializer (created by default if you use Zend Studio for Eclipse 6.1).

Prepare your application

The first step is to create an automated testing environment is the correct preparation and configuration of your application. Depending on your setup, this may include setting global variables, changing relationships of the database, or reconfiguring routes. Fortunately for us, this is easily done by using a plug-in controller Zend_Config and Initializer.

Zend_Config allows you to assign "sections" that can be inherited from another topic. This allows you to change the configuration for different environments without duplication of facilities in different files (and thus helps us make sure we have not forgotten anything!). In our test project, we need only change the connection string to the database, so we use the test database.

Notice how we can inherit the attributes of the child: even though we have assigned a node, we did not need to assign anything below it. Now that all our settings right, we need something to control them, and off based on the environment in which we operate. This is the role of our plug Initializer, which takes the environment to initialize a constructor parameter.

A simple example.

Let's start with a simple test framework controller. If you are using Zend Studio for Eclipse, you can easily create this structure by right-clicking on the controller in the PHP Explorer, go to New> Zend Framework Item and then select the Zend Controller Test Case. Then just make sure the controller you want to test is selected and click finish.

As you can see in line 21 we use our initializer to set the test environment to run the tests. Before each test run, PHPUnit will cause our method setup (), which was programmed to run our method appBootstrap.
This assures us that we are using a clean configuration and Wednesday before each test, the same as if each test was a separate process. When all tests are passed, the method tearDown ().
This is the place for any code that removes resources or discards any changes that could make the tests. We have a handy later in our advanced examples.
Line 45 contains the skeleton of the test conditions, which will ensure that the dispatch of the results '/ index / index' in the controller named 'index' and the action called 'index', was launched last.
This may seem trivial, but it will help detect errors related to your controllers.
If it detects an uncaught exception, the statement of the controller to be erroneous, since it will run last.

Run your tests

That article was focused, I decided to delete this section and tell us only about writing tests. If you need help in the creation of Test Blocks and run tests from command line, see the documentation for PHPUnit, especially the section on running tests from the command line and the organization of the test blocks.
Increased functionality testing
Now that we've covered the basics, let's move on to testing our controllers accounts. There are a couple of additional requirements for testing the controller accounts. First, we need to test the entire process of creating the account as if the user is actually logged. When we have finished testing, you need to get rid of all the possible data so that we can run the test as many times as necessary, and not worried about the increase in the database. Second, we need a way to simulate the operation of this user, absolutely, as well as to check whether it is real.
Since these operations are quite common, and have the opportunity to re-use, let's put them in a separate class and allow them to inherit the test conditions.

One way of testing the model

There are two ways to make sure that the data generated during the test will be deleted after execution. Some prefer to create databases on the fly, using the original data.
Since I use Doctrine to my projects and work directly with the model (without serious requests) in the tests, I decided that simply removing the data will be the best solution.
To accomplish this, all we need is "assign" our model for the removal, after it was created (or loaded).

It simply makes reference to the model, and stores it in the array, which later will be managed by our function tearDown ():

We simply runs through all of our "designated" model and the delete them. This should be done in tearDown () and not within any of the methods of test, since it is the only way to be sure that it will happen.
When the statement is incorrect or unexpected exception occurs in the test, this method stops run. If we try to put our models after the approval (assert), it may never happen.
In the same way, we obviously can not have a model to the assertions, if this model is needed for the assertions (and why it could not exist if it is not necessary?).

Support for authentication

Only 3 things that we should be able to make a full turn for the test authentication.
* Create a false identity
* Install our environment in a state equivalent to the user who logged on to the system
* Whatever the state of the environment, to approve the state produced by the entrance

Our example uses a controller card database for authentication and search for identity, hence, the generation of a false identity means to us to create (or download) records in our chart of accounts and returns the ID database, which we usually get.

The account is our model, type Doctrine_Record. We simply create a random account and return the data as our ID. Please note that we also found this model to remove (as shown above). Now we need to find a way to set our environment to the state "logged in", as it is a fake user.

In our sample application, if Zend_Auth has an identifier, then the user has made entry into the system. Consequently, all we need to do is to store the identifier in the storage adapter Zend_Auth, and be entered into the system. This makes the input assertions is as simple as checking the ID.

This simple assertions provides assurance that we have made (or not made) logged on.

Fold it all together

Adding it all together, we now have a base class that provides all of our cases test the functionality we need.

Writing a test controller

Now that our foundation is laid, we can finally start writing the test controller. Our first unit test case will cover the following requirement: "When users register, they must confirm their e-mail address before they can access their account."
To do this we need to simulate a user sends its correct registration information in our controller and check to set up the account has not been confirmed.
Then we have to test that sent a login for unconfirmed account will not result in the user's authorization.

Our first test simply uses the global variable $ _POST to simulate sending our registration form, with some test data. After dispatch (), we use the model to search for Doctrine_Table created AccountController :: registerAction (), then the claim that the record was found and that it was not marked as confirmed.

The second test runs manually inserting records that have not been confirmed, and give confidence that users will not pass authentication when trying to make an entrance with this information on your account. As an added bonus, we also use assertNotRedirect () to make sure that our controller does not redirect. Our controller needs to do a redirect only if a successful login, otherwise it would have introduced a user error.

Post a Comment

Name: (Optional)
Email: (Optional, you can get an email if somebody replys your comments)*
Email me if somebody respons my comment below:
Enter Text
as Below:
(case insensitive, if hard to read, click the "get a new one" button)
* Your email address will not be shared with any third parties for any reason.
** Maximum 1000 charactors.