·

photo credit: lovestruck...(my Mac got wet... Waiting for it to via photopin cc

Magento unit testing with specific customers

Sometimes you have the situation where you have to write unit tests for Magento that involves Magento customers. If – for example – you have some business logic that depends on certain customer- (or address-) attributes, you want to make sure your code works as expected before you’re deploying it to a live server.

Unit testing in Magento can be useful for this kind of situation, but where do you start? Customers are stored in the database so you need to fetch your data from there. But you also want to keep your tests self-contained and maintainable. This article explains the basics on how you can write unit tests for Magento that test your customers’ logic.

Setup your test

You really need to read this article first before you start with this one; it explains a certain approach for Magento unit testing. Especially on how you can write self-contained tests for Magento by creating test tables in your database and changing configuration on the fly. This approach is also used for the basic setup from where this example will derive.

Customer test data

The first thing you have to do (as described in the above mentioned article) is create a setup.sql -file filled with customer test-data. Depending on what you would like to test, your sql-file could look something like this:

This sql-file creates the customer and address (test-) tables, both prefixed with the prefix test_ . Please note that we stripped the foreign key constraints so we don’t get conflicts when trying to drop or create the tables. Unless you want to test if these are working (like MySQL’s CASCADE and stuff), you don’t need these in your test database anyway, since the tables are dropped and re-created each time the test is run.

Temporary change the configuration

Make sure your unit test tells Magento to use these test tables when it comes to customers (and addresses). Add the following code to the setUp() -method of your test class:

These two lines tell Magento that when it comes to loading customer data, don’t use the default tables in the Magento database, but the prefixed ones. Don’t worry about EAV: By changing the main table name, Magento will also look in the prefixed EAV-tables (test_customer_entity_int , test_customer_entity_varchar , etc.).

Custom attributes

There are situations where you need to add the custom attributes you’ve added to a customer or to an address. But with custom attributes that are added to the database later on, chances are that the ID’s of those attributes differs between different environments. In those cases it might be advisable to read the ID of the attribute in question from the database, and re-create some database records after the import of setup.sql . You can do this by adding the following lines to your setUp() -method in your test class:

Do your test

When all is up, set and prepared, you can now go right ahead to the fun part: writing your test. Since you know the structure and ID’s of your testdata, you can now load a customer in your test as you would load it in your actual code, and do some magic with it. For example:

Do tests with logged in customers

When you want to test something with logged in customers you can mimic the login of a customer by setting the customer in the session. Don’t forget to ‘logout’ your customer when you’re done with your assertions, otherwise the customers stays logged in, possibly ‘polluting’ other tests:

Note that we have a different way of logging our customers in and out. Instead of using the default login() – and logout() -methods of our session, we use the setCustomer() -method to mimic a login and logout-action. We do this because otherwise Magento will send output headers and those will break our test. And we don’t want that.

In conclusion

In this article I explained how you can setup a unit test in Magento to write tests that involve customers. As usual there is always room for improvements, but this is one way on how it can be done (and how I am currently doing it). I hope it can help you on your way in writing better unit tests for your next Magento project. If you have any tips or suggestions, please feel free to place them in the comments below this article.

I’m still fairly new to the world of unit testing and the more I can learn, the better. Even now, when I’m writing this article I get the feeling I can think of a better, more maintainable way of creating and loading test-tables in the database. So who know… perhaps there will be another follow-up in this subject soon…

Visitors give this article an average rating of 4.5 out of 5.

How would you rate this article?

Leave a Reply