My friend and fellow teammate - Trung - has been spending time with me to help me understand how to debug failing tests and code.
He showed me how to put break points in Eclipse and then to run the test in debug mode. When it hits the breakpoint, the test can move line by line of the code - by hitting F6. F8, will run through the rest of it without break/stopping.
This has helped me zoom in closer to problems I was reporting. Such as a variable not being set before the page continues.
15 March 2011
03 March 2011
First Acceptance Test!
Pretty excited. I put together my first acceptance test today.
One problem we're running into is the lack of ID's on elements. We don't want to use x Paths to find elements on the page. So when I created this, I hit this problem... my dev's Trung and Victor were able to add ID's for me and I put together a communication test!
I login as a matched user, select a match, pull up their details and send an icebreaker. It's pretty cool!
So in case I've been remiss in describing these acceptance tests... The goal is this:
Each time a developer commits code, a build goes out and all the acceptance tests are run in a Continuous Integration environment.
These tests call a browser, and run through the automation of the browser to test the code. The more tests we have, the better and faster we'll catch a problem introduced through a commit.
How we automate this is in a Groovy/ Spock framework.
We have pages and tests. under the pages, we have each page being it's own Groovy Class. Then the tests themselves call each page, as an objects. This page object methodology makes it easier to understand whats going on, create tests and see where the failures are occurring.
For example:
If I wanted a test that would
Go to a Login page
Send valid login credentials
Get to a welcome page on the other side
Verify I'm at the welcome page
Logout
Verify I'm back at the login page
We set it up by making the page objects:
Loginpage.groovy
Welcomepage.groovy
The test:
logintest.groovy
would call the loginpage class.
Like
loginpage(username, password)
.logout()
One problem we're running into is the lack of ID's on elements. We don't want to use x Paths to find elements on the page. So when I created this, I hit this problem... my dev's Trung and Victor were able to add ID's for me and I put together a communication test!
I login as a matched user, select a match, pull up their details and send an icebreaker. It's pretty cool!
So in case I've been remiss in describing these acceptance tests... The goal is this:
Each time a developer commits code, a build goes out and all the acceptance tests are run in a Continuous Integration environment.
These tests call a browser, and run through the automation of the browser to test the code. The more tests we have, the better and faster we'll catch a problem introduced through a commit.
How we automate this is in a Groovy/ Spock framework.
We have pages and tests. under the pages, we have each page being it's own Groovy Class. Then the tests themselves call each page, as an objects. This page object methodology makes it easier to understand whats going on, create tests and see where the failures are occurring.
For example:
If I wanted a test that would
Go to a Login page
Send valid login credentials
Get to a welcome page on the other side
Verify I'm at the welcome page
Logout
Verify I'm back at the login page
We set it up by making the page objects:
Loginpage.groovy
Welcomepage.groovy
The test:
logintest.groovy
would call the loginpage class.
Like
loginpage(username, password)
.logout()
Subscribe to:
Posts (Atom)