There's a great blog about REST (what it is, explanation and examples) at:
http://rest.elkstein.org/
http://rest.elkstein.org/
23 November 2011
15 August 2011
New Version of GEB
Thanks to some developer help, we now have a newer version of GEB running. This new version may help rule out some of our non deterministic tests.
The idea is that it now handles webdriver and selenium a lot better.
Also - the older GEB couldn't run screenshot compatibility. Now the latest and greatest GEB brings that back. So we run the Continuous Integration tests... check the results, in Hudson - and have linked .jpg's of each screen in the test run.
The idea is that it now handles webdriver and selenium a lot better.
Also - the older GEB couldn't run screenshot compatibility. Now the latest and greatest GEB brings that back. So we run the Continuous Integration tests... check the results, in Hudson - and have linked .jpg's of each screen in the test run.
29 July 2011
Jez Humble
Jez Humble was at our offices today, giving a talk on Continuous Integration... unfortunately I missed it - due to working on some issues with our Acceptance Tests, and filling in while my Manager is out with some other work.
Ah well, maybe next time!
Jez Humble runs: http://continuousdelivery.com/
He also is a published author: http://www.amazon.com/gp/product/0321601912?tag=contindelive-20
Ah well, maybe next time!
Jez Humble runs: http://continuousdelivery.com/
He also is a published author: http://www.amazon.com/gp/product/0321601912?tag=contindelive-20
Found the Problem
At 10am we were down to 2 failures.
In looking at one of the acceptance tests I found the problem, by running it locally.
It failed when FF went through the same flow but then got a new overlay on one of the pages. Here's the deal... our acceptance tests are in two frameworks:
a) homegrown groovy/spock framework
b) GEB framework
We're actively trying to convert all acceptance tests to GEB. However, this has left older tests not yet converted in the lurch. In this case, the code we needed to bypass the new overlay, wasn't in the test.
Our decision was to convert the test to the new GEB framework.
So the developer on my sprint team: Vijay - he migrated the test over to GEB. I sat down with him and went through the flow of converting the test. It was pretty cool. Seems so much easier when a developer does it.
In looking at one of the acceptance tests I found the problem, by running it locally.
It failed when FF went through the same flow but then got a new overlay on one of the pages. Here's the deal... our acceptance tests are in two frameworks:
a) homegrown groovy/spock framework
b) GEB framework
We're actively trying to convert all acceptance tests to GEB. However, this has left older tests not yet converted in the lurch. In this case, the code we needed to bypass the new overlay, wasn't in the test.
Our decision was to convert the test to the new GEB framework.
So the developer on my sprint team: Vijay - he migrated the test over to GEB. I sat down with him and went through the flow of converting the test. It was pretty cool. Seems so much easier when a developer does it.
Bye Green, Hello Red
5 new failures in the same trunk that was green yesterday.
Having an issue with the old "element not found in cache."
Googling it, I came up with:
http://code.google.com/p/selenium/issues/detail?id=1887
http://www.echographia.com/blog/2011/01/13/element-not-found-in-the-cache/
Having an issue with the old "element not found in cache."
Googling it, I came up with:
http://code.google.com/p/selenium/issues/detail?id=1887
Comment 3 by leo.lath...@gmail.com, Jun 25, 2011
This happens for me a lot. I suppose that my page is too dynamic and it invalidates the references too often.
So I had to add a catch for the StaleElementReferenceException and retry the instruction for every selenium find. For me, that doesn't make much sense.
If the cached element is stale, shouldn't the cache miss trigger a new request to refresh the element?
Comment 4 by savag...@mail.ru, Jun 26, 2011
Thanks for your advice. I added a catch and everything works, but... it looks like a workaround or something like that. I thought it should work automatically.
http://www.echographia.com/blog/2011/01/13/element-not-found-in-the-cache/
26 July 2011
Green!
Our tests are green again.
Jenkins - reports that the latest trunk build has no Acceptance Test failures.
That's awesome.
We do have some skipped tests - that's the next thing we're tackling... how to reduce these non-deterministic errors.
Jenkins - reports that the latest trunk build has no Acceptance Test failures.
That's awesome.
We do have some skipped tests - that's the next thing we're tackling... how to reduce these non-deterministic errors.
18 July 2011
9 Failures
This morning I came in to work and checked in with Jenkins Continuous Integration/Deployment results.
We had 9 failures reported in Jenkins. I pulled in the latest code through Eclipse:
team > Update to Head
I ran these tests locally, against a QA environment:
Run As JUnit tests
I saw the problem. We have a new page that appears if a user goes to their Dashboard, after logging in. This new page, wasn't being accounted for in these tests... but other tests worked fine.
Turns out it's because of our migration to GEB. We have tests in two frameworks currently. The GEB framework and the older homegrown Groovy/Spock framework. The fix to pass this new page, was put into the older framework. However it wasn't put into the newer GEB tests.
So I was right about the problem.
However, my fix, which was a simple if statement - didn't work out so well. I pulled in a developer (Vijay) and he corrected my code.
We're considering a better solution, which is to create users who don't pull these features (like having the necessary data populated at the beginning of the test) so the feature wouldn't pop up anyway.
We had 9 failures reported in Jenkins. I pulled in the latest code through Eclipse:
team > Update to Head
I ran these tests locally, against a QA environment:
Run As JUnit tests
I saw the problem. We have a new page that appears if a user goes to their Dashboard, after logging in. This new page, wasn't being accounted for in these tests... but other tests worked fine.
Turns out it's because of our migration to GEB. We have tests in two frameworks currently. The GEB framework and the older homegrown Groovy/Spock framework. The fix to pass this new page, was put into the older framework. However it wasn't put into the newer GEB tests.
So I was right about the problem.
However, my fix, which was a simple if statement - didn't work out so well. I pulled in a developer (Vijay) and he corrected my code.
We're considering a better solution, which is to create users who don't pull these features (like having the necessary data populated at the beginning of the test) so the feature wouldn't pop up anyway.
Subscribe to:
Posts (Atom)