If you use the page object pattern when setting up e2e tests (as they are written in the gulp-angular yeoman generated project) then you might want to check that the properties of this page object are actually elements that exist on your page. Indeed, checking that my page object elements exist is almost always the first protractor test that I write. I naively tried a method that didn't work so great at first before finally finding the glorious "isPresent()" method available on my page object elements.
Here's the code from the file where I'm defining my page object:
And here is an example of a BAD assertion statement that won't work right in Protractor tests.
The problem with this approach is that inside of e2e tests the idea of defined or not defined has a different meaning. Relying on what is returned from the "toBeDefined" method is not going to work because even things that don't even in your document will come back as defined, and your protractor test runner will explode if you try something like this:
It'a sad to see Protractor test runners suffering like this. The real problem with our code up there though is that "toBeDefined" is a Jasmine matcher, and when writing Protractor tests you're going to have to use Protractor matchers. Luckily, there is a Protractor matcher that does basically exactly what we're trying to get at.
Like most software bugs that come up all these problems were caused by my own errors. :)
Is pretty easy to solve this particular problem though. After a quick google search and a peek at the protractor documentation you might learn that "checking is an element really exists on the page" in Protractor terms would be getting a reference to that element and calling .isPresent() on it.
Or if you prefer you could use the toBeTruthy / toBeFalsy matcher:
And we can even check that elements that shouldn't be present are actually not present:
If you are just doing this for the first time then I'm actually really jealous of you. This is a really exciting time because it means that 1. you are up and running the "page object" protractor pattern so you have a clean way of accessing ANY element you can possible have in your website / web app and 2. you are able to test whether they are present in the page. If your test is checking that the element is in fact present and it's passing, then you can really trust that it's testing the actual elements on your page! From here you can start checking the text in elements:
look at css properties:
or even send fake mouse events to them:
Although this is a very fundamentally different approach from Unit testing, automated testing with Protractor is a fun and exciting world in it's own right, and the sooner you start writing these tests the better off your software will be. :)
The posts on this site are written and maintained by Jim Lynch. About Jim...