Topic: continuous integration

Can your Selenium do that? Testing flash/flex and silverlight in web apps with iMacros

John McCaffrey, Wednesday, April 8, 2009 @ 4:00 am

Having learned a long time ago the value of automated testing tools like Selenium, jMeter, and soapUI, I'm always on the lookout for new improvements in these tools. While I love Selenium and other frameworks like it, it has the limitation of not being able to test Flash/Flex/Silverlight or Java Applets. But if you need to test flash and silverlight components of your web app, in an automated way, the  iMacros testing tool might be worth checking out.

No Free Ride

While the free version of the iMacros plugins for InternetExplorer and Firefox allow powerful web scripting similar to Selenium, to be able to do the flash/flex and silverlight, you have to get the paid version or the 30-day trial. I downloaded the trial version to see how it compares to Selenium and what kind of damage I could to.

Going through some of the online demos, Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Continuous Integration Meets Risk-Based Testing

Ivan Moscoso, Thursday, December 18, 2008 @ 1:30 pm

A new version of TeamCity is out, and while I have not taken it for a ride yet, I found this feature particularly interesting:

Risk Group Tests, Tests Re-ordering
TeamCity 4.0 is now able to determine a set of tests which are likely to fail (i.e., recently modified, those with frequent failures history, etc.), and perform those tests first the next time the project builds. This allows teams to confirm potential fixes sooner, reducing feedback time.

There are strong cases to be made for risk-based testing in certain environments. The reason why it is not more commonplace is that implementation is tricky since it requires the CI system to know a few things which are hard to generalize:

• The type of build and testing framework
• Historical perspective across multiple builds
• A good set of heuristics along the way

Since a risk-based approach may mean skipping certain tests on some builds, this may sound like a step backwards to the agile developer. But consider it an alternative to improving overall build time (i.e. "based on very low risk assessment, tests which never failed will not be run every time."). The hard part is defining what "low risk" means to your project, and how much value you would get reducing overall build time.

This is obviously not an issue on well-run projects with sub-minute builds, but if you were to be dropped into an existing project with, say, a large code base and a fifty-two minute build (I've seen it), this can become one way to perform triage on an otherwise untenable position. You don't need a new CI system to implement risk-based testing, but having this alternative can't hurt.

• Digg
• Reddit
• del.icio.us

Comments (0)

software development best practices