As a very quick summary, Page Objects are a way to group all the commonly used parts of a specific page in our site, such as the pages URL, the Username field, or the Password field, or the Repeated Password field, for example.
The advantage of doing this is to centralise all the things that might change inadvertently throughout our projects life cycle, but that we don't want to have to do messy find and replaces through multiple tests, or worse, multiple test files to update to the new paths.
To generate a page object, if you've been following along with this course, you're going to want to run a command similar to the following:
php vendor/codeception/codeception/codecept generate:pageobject LoginPage
Codeception will then spit out an 'empty' PageObject file into the /tests/_pages directory ready for your customisation.
The names you give your PageObject variables should be in context with whatever is on your page. In our example it's a login page, so
$passwordField make sense, as these will be fields on the page that we are interested in.
The contents of these variables can be various things to identify what you're targeting, but personally I find CSS id's and class names to be easiest. XPath is a bit of a nightmare, and names change too frequently to be reliable in the long term.
This is where Chrome Developer Toolbar or Firebug will really help you out.
PageObjects are really pretty straightforward. They help you centralise and manage common parts of a page in your test suite. That's about it. But don't be fooled by their simplicity, they really are very useful, and once you start using them, not only will your tests become cleaner, but your maintenance will become easier, and that means more time spent doing more interesting things.
StepObjects are a little more involved.
In summary, they are a way of centralising and managing commonly repeating actions in your tests. Login is a great example of this, as you will likely need to perform the same Steps over and over in your tests to ensure you're user is logged in, and the last thing you want is to be repeating yourself. Even in tests, you should be *[DRY].
Again, if you've been following along and have things installed and setup the way I do, the command you will need is similar to the following:
php vendor/codeception/codeception/codecept generate:stepobject acceptance UserLogin
You'll be prompted for a Step name here, so be sure to think up something suitable. Or not. You can always change it. Nothing is ever set in stone.
As you'll see from the output, the StepObject files get dumped out into a
_steps directory, but that will be a sub directory of whatever suite name you gave in the command. In our case, our StepObject will be output to /tests/acceptance/_steps/UserLoginSteps.php
In the video (around the 6:00 minute mark onwards), you will start to see just how powerful a combination of PageObjects and StepObjects can be to simplify the flow of your test environment.
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Installing Codeception in Your Symfony 2 Project||04:20|
|3||Codeception's Folder Structure||06:42|
|5||How to Run Codeception Tests||02:43|
|6||Our First Acceptance Test||08:00|
|7||An Alternative Perspective on Acceptance Testing||04:33|
|8||Acceptance Testing Symfony Forms||08:22|
|11||An Introduction to Unit Testing in Codeception||04:24|
|12||Unit Testing a Symfony Service||11:59|
|13||Integration with Symfony 2||06:27|
|14||Databases and Unit Tests||14:21|
|15||Real World Unit Testing - Database Clean Up Issues||06:15|
|16||Fast PHP Unit Testing with SQLite Database||10:19|
|17||Mocking the Entity Manager||20:22|
|18||Codeception Selenium Setup||06:08|
|19||How to Setup XDebug with PHPStorm||07:36|
|20||Step Objects and Page Objects||09:35|
|21||Fizz Buzz Kata||24:43|
|22||Code Coverage Reports||10:10|
|23||Running Acceptance Tests Faster With Phantom JS||01:30|
|24||Mobile Browser Tests||01:18|