In the previous article, we finished up our acceptance test for the process of creating users in the MODX Manager. In this one we'll begin a series of articles with a little more ambitious test — one that tests the security system that controls which users can see or not see a given resource.
We'll also see how Codeception StepObjects work and we'll use one to create a complex set of MODX objects before our test begins. There will also be some more examples of complex XPaths used as locators for elements in the MODX Manager and a raw data file.
This article assumes that you've installed and configured Composer, Codeception, PhpUnit, MODX, Java, WebDriver, and ChromeDriver as described in earlier articles, and that you've created the acceptance test support files from those articles.
Skeleton Resource Protection Test
In the _build directory, enter this command:
codecept generate:cest acceptance T16_ResourceProtection
The idea for this article came from an experience with the MODX 3 alpha. I was testing the visibility of protected resources and found that doing the test was particularly tedious. I had to create users, user groups, roles, protected and unprotected resources, resource groups, policies, and Access Control List (ACL) entries. Then I had to log in as each user and check the visibility of the public and private resources. It was a huge pain. It should really be done every time there's a significant MODX upgrade, but I suspect that it's often neglected because it's so tedious and time-consuming. It's the perfect task for an acceptance test. I should mention that the MODX 3 failed the test when I originally created the test. I reported the bug, and it's now fixed. The test was able to confirm that the fix worked.
I mentioned MODX 3 above, but the initial tests in this article will only work in MODX 2. I created them using MODX 2.8.1, but they should work with any recent 2.x.x version. In later articles, we'll look at making the same test run in MODX 2 and MODX 3.
Test Overview
In our test, we'll create three users: an admin super user (JoeTester), a user who should see the protected pages (PrivateUser), and a user who should not (PublicUser). We'll also create corresponding user groups (PrivateUsers and PublicUsers, a role for those users (TestRole), a protected resource (PrivateResource) and an unprotected resource (PublicResource). We'll also create two corresponding resource groups (PrivateResources and PublicResources), and finally, an ACL entry to protect the "Private" resource.
We could create all these objects using Codeception acceptance test methods to navigate through the Manager, fill forms, and click things in order to create the objects. The problem is that our test would be testing too many different things. It would also take a much longer time to run.
Creating objects like roles, users, user groups, resources, and resource groups should be done in separate tests that have a single function. We'll create the objects in code and remove them all at the end of our test. That way, our test itself will only be testing one thing: the process of hiding resources in the Manager with an ACL entry.
Once everything has been created except the ACL entry, we'll log in as the admin user and create the ACL entry. Then, we'll log out, log in with each user, and make sure they see what they're expected to see.
Codeception StepObjects
Step objects in Codeception are very much like helpers and page objects. Helpers are intended to help with a particular test or suite of tests. Page objects are to hold information about specific pages, either in the front end, or the back end. Step objects are for use when you have an action that might be used by a number of different tests, such as the creating users, logging in, clearing the cache, and so on.
In previous articles, we created a fairly complete acceptance test for the process of creating users. You can imagine that you might also have separate acceptance tests for creating resources, resource groups, user groups, and roles. This test won't be testing those processes. We'll create all those objects using the methods of a StepObject class we'll call Objects.
Once the objects all exist, we'll test the ACL process by logging in the admin user to create the ACL entry that protects the hidden resource, then log out the admin, and log in each of the non-admin users to see if the ACL entry works as it should.
The first thing we'll do is create the step object we'll use to create the objects used in our test. Codeception has an interactive command-line process for creating step objects. When you give the command to create the step object, Codeception creates it, and then prompts you for the names of the methods you want in the step object class. You just type the method names followed by Enter. To end the process, you press the Enter key without naming a method. Creating the methods is optional, but it's handy if you have a lot of methods.
Coming Up
In the next article, we'll go through the process of creating our Objects step object.
For more information on how to use MODX to create a web site, see my web site Bob's Guides, or better yet, buy my book: MODX: The Official Guide.
Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at A2 hosting. (More information in the box below.)
Comments (0)
Please login to comment.