One of the tenets of the agile methodology is feedback. To provide value to your customer, you need to know that what you are delivering is correct. But as an agile coach, I often struggle with teams understanding the importance of getting feedback from the customer as soon as possible. One way to get teams to understand is to use an analogy – cooking.
Spring is an essential part of my technology stack. I cann’t image providing quality software that doesn’t leverage an IoC container. However, decoupling components requires some amount of configuration. Whether this is accomplished through annotations or XML, it’s fairly easy to mess up. Fixing these missing or incorrect configurations doesn’t take very long. The real question is how quickly can you identify these errors?
This question of how long, is a feedback loop question. Unfortunately many teams wait until they fire up the application server to see if their Spring context is wired correctly. This is too late.
One of our clients suffered from this very issue. Due to environmental constraints they could not run automated, in-container tests that would have identified misconfigured beans. After repeatedly committing stupid configuration mistakes, I decided that I would write a Spring wiring test. As I began to write this I encountered five problems.
In Part I we covered
- Setting Up
- Recording Tests
- Playing Back Tests
- Saving Test Cases
- Resuming Recording
- Saving Test Suites
All examples will use the sample site https://sites.google.com/site/example4selenium/.
- There are two ways to store values.
- First, you can define custom variables
- Second you can use the drop-down ‘storeText’ option.
I primarily use Selenium IDE in three areas:
- Defect – I ask testers to record their steps and attach the script to their defects. This is a simple way to communicate exactly how they found an issue. This technique significantly cuts down on communication overhead.
- Acceptance Testing – While I prefer writing tests before I write the code, this is a simple way to record tests on existing web applications. In part II I will show you how to export these recordings into Java. By exporting these scripts you can easily add them to your existing automated test suite.
- Demo Setup – I’ve found it handy to run small Selenium test cases to setup a demo. For example you may want to demonstrate the functionality on the tenth page that requires a log-in and multiple data entry steps. This approach can reduce demo setup time and enable you to focus on demonstrating new functionality.
Transactions are an essential component in enterprise software development. When your application works properly you rarely think about transactions. However, when things go wrong debugging transactions can be quite challenging. Instead of being reactive we need to proactively test our transactions.
When I first got into the software industry I was a manual tester. Those years of repetition and tedium drove me to the world of coding and automation. As a software developer I am committed to automated testing. If a feature is worth coding it is worth testing. Automated tests have positioned me to be proactive instead of reactive. Nevertheless, transactions are quite challenging to test.