Testing WordPress Plugins with Codeception. Part 2
Published on August 01, 2013
In previous part of this tutorial we installed Codeception and got a simple test for User Submitted Posts plugin. We tested that user can send a post and see a message that the post was successfully sent. Nothing more.
Let’s remind the test
SubmitPostCept we done previously:
But well, we didn’t verify that the admin has received this post. And it can be published after a moderation.
Thus, we will require few more steps to make a test complete. We will need to login to WordPress admin dashboard.
Test commands which allow us to do that are pretty obvious. To keep the code listing shorter we won’t show the code from previous lesson. But you should understand that we just append new commands to the previous steps.
Then we go to Posts section to get all the post listed. We expect to see the “Game of Drones” post in the list.
Let’s also check that it was not published by default and it is in
Game of Drones Review - Pending should be found inside the
table html tag, right? We can even specify the CSS class
.posts for that table.
That’s right, the
see command we use for assertions (and the test will fail if assertions fail) has a second parameter which allow us to narrow the results from the whole page, to a particular area on a page, which we can define by CSS:
What’s left? We need to review and publish this post, right?
The result we expect… Well, we will trust the notifications once again, and message Post published should be enough for us.
And that’s how we will do that in test.
And that would be a good point to execute tests once again. Probably you remember, that you need execute
run parameter from console.
What we are seeing now? Oh no. Just another fail.
What could go wrong? Hopefully Codeception gives us a suggestion to look for the complete HTML code in
_log directory. This directory, actually
tests/_log, was meant to store all data related to test execution. We can see there two log files, and the file which we actually need:
This file, named after our test name, stores the HTML that was on page, before the fail. Let’s open it in a browser to get a clue what might go wrong here.
It looks like we are still on the Edit Post page we were before. And the post status is still
Pending Review. It looks like
click('Publish') command didn’t do its job.
Take a look on screenshot. as you can see, word Publish occur several times on a page. We can assume that we were clicking wrong one. What should we do in this case? We can specify the exact that blue Publish button with CSS.
Codeception can use CSS instead of names for clicking the elements. The button have
id=publish attribute, thus, it can be found by
#publish selector. That what we would probably do if we were using jQuery.
And that fixes the test. You can check that by executing test once again. Let’s not trust the notification test and check that a post really is on site. We can click
View Post link right near the
Post updated message.
What we will check that there is site motto on a page (thus we know, we see the blog theme),
and that post title is shown in
.entry-title class. And yep, we see this story is “epic and amazing”.
Let’s face the final and complete code of our test:
Well, we did a good job. But the test is like too long. And we can’t understand what was going on here.
We can add comments to the code, and Codeception has some valuable helpers to add extra text informations with
We divided our test scenario into logical parts. At least we have left some notice about what is going on and what we were going to achieve. If we execute test with
--steps option, we will get a output with all passed steps listed:
Our comments were added to list of passed steps, thus we can easily understand what was going on.
And that’s quite enough for today. Our test is pretty mature, and covers not only plugin functionality, but WordPress core functions too. Whenever this plugin gets updated, this test should pass to ensure we did everything right.
But the only thing left. After we executed tests several times, we got this picture on
We have attack of clones here. Yep, each test created its own post and published it. Probably, it is not a good idea to pollute the blog with dozens of posts with similar names. We use post title and content in a test, so probably we can’t be sure, what post we are dealing with: current one or the post from a previous test.
That will lead us to the idea of data cleanup. Probably we should delete post after it was published, to revert all our changes. Alternatively we can install WordPress Reset Plugin to reset WordPress to its initial state. In both cases we will need to append some steps to our test to get data cleaned before the next test.
Let’s make this your home task. To not start with scratch, you can download code of this tutorial or clone it on Github.
In next lesson we will try to refactor this test and get a few more of them. Don’t worry, they will be much shorter than this one. See you soon!