Wes Maldonado: Data Junkie

Agile teams need tools that separate the essence of the test from the implementation details. Such a separation is a hallmark of good design and increases maintainability. Agile teams also need tools that support and encourage good programming practices for the code portion of the test automation. And that means they need to write the test automation code using real, general use languages, with real IDEs, not vendor script languages in hamstrung IDEs.

Agile Friendly Test Automation Tools/Frameworks

People keep asking me how to start writing Selenium tests. I’m going to give all my secrets away in this easy 3 step plan.

1. Begin by recording your high level test with Selenium IDE, convert the result into the language of your choice and put the code in a unit test.

2. Walk through the generated code and extract “page” into an object, use these to develop a Logical Functional Model of your application.

3. Consider decomposing page elements into objects to make the test code more clear.

Yes, it’s that easy… just give it a try and leave comments if you have questions. And of course, I have to provide the obligatory link to other Selenium related posts I’ve written.

People seem to have some problems when it comes to testing file uploads with Selenium RC. I’m not the first to provide a solution but making this work with Selenium RC might take a few more steps.

With Selenium RC you get a fresh browser each time you start a test run. So you’ll need to add this to your default profile in a You can upload files with Firefox if you build a custom profile with relaxed Javascript securities. You wouldn’t want to run this relaxed security version against any code that you don’t trust obviously, so be careful.

Step 1. Create a new Firefox profile. Step 2. Edit prefs.js to include:

user_pref("signed.applets.codebase_principal_support", true);

Step 3. Modify your AUT (this is why this is bad way to test file uploads via Selenium) to request enhanced permissions via:

netscape.security.PrivilegeManager.enablePrivilege("UniversalFileRead"); 
// This gives Javascript the ability to open file:// URI's.

Step 4. Visit your AUT using the profile you’ve just created, you’ll hopefully be greeted with a warning asking you if Javascript should be allowed UniversalFileRead permissions. Clicking yes will add entries to your prefs.js file that look like the following:

user_pref("capability.principal.codebase.p0.granted", "UniversalFileRead");
user_pref("capability.principal.codebase.p0.id", "http://your_aut_domain.com");
user_pref("capability.principal.codebase.p0.subjectName", "");

You can then edit your SeleniumRC instance to launch FireFox using this specific profile.

You can, and probably should, go farther with this by granting per file permissions.

More info:

• Mozilla.org Signed Script Example
• Mozilla.org JavaScript Privileges List

The MOntreal Internationalized Software Testing conference possibly has the worst conference abbreviation ever: MOIST

I’ve never been against the word myself, but others really think it’s gross.

I’m sold on BDD and have mentioned it a few times and now here I go again. I’ve already told you I’m a fan of ridiculously long test names. When asked why I’m a fan of BDD I’m now going to reply that it’s about awesomely readable tests.

So, BDD is just writing tests with a special syntax and describing them in plain jane English. “What’s the big deal, then?” Nothing. There is no big deal.

However, if you’ve a bit of time and an inclination for writing awesomely readable tests (which may ultimately help you write better code), continue.

Developing a Rails model using BDD and RSpec, Part 1

Developing a Rails model using BDD and RSpec, Part 1 is a great step by step guide for using RSpec/BDD for Ruby on Rails development.

I was reading Ted Carnahan on ticky tacky and it reminded me of code duplication. Ever start feeling like you’re in a pre-fab sub-division when you’re looking at your code? You might just have some code duplication to take care of.

The phrase ticky tacky was coined by Malvina Reynolds in the song Little Boxes made popular again by the show Weeds.

Ticky tacky: Sleazy or shoddy material used especially in the construction of look-alike tract houses

http://www.m-w.com/dictionary/ticky-tacky

Next time you’re refactoring your tests to reduce test code duplication hum along to this Elvis Costello cover of Little Boxes with some altered lyrics:

Little methods in the editor,

Little methods made of ticky tacky

Little methods in your classes,

Little methods all the same,

Theres a green one and a pink one,

And a blue one and a yellow one,

And they’re all made out of ticky tacky

And they all look just the same.

What’s too much modeling?

Too much formal modeling is when you give it more time than it is worth, or when many other interesting things don’t get done because you are obsessed with the formalisms and the cool tools. Too much attention to one kind of model will starve attention for other kinds of models that also have testing value.

The Unbearable Lightness of Model-Based Testing

For me, it’s always the cool tools. This time it happened to be Selenium. I must work on this terrible habit of mine.

I was reading Why Rails Fixtures are No Fun last week and was going to write a great post about xUnit Patterns that would address the problems but today I saw Object Mother In Rails so I don’t need to write it up. Phew!

From Opensourcetesting.org News

shUnit2 is a xUnit based unit testing framework for shell scripts (eg. sh, bash) that is modeled after the JUnit framework. It is designed to make unit testing in shell as simple as possible.

I’ve writen about being an SDET before and now here is Google’s take on the definitions of Quality Assurance (QA), Quality Control (QC) and the roll they call Test Engineering.

Here at Google, we tend to take a third approach that we call Test Engineering. We look at this as a bridge between the meta world of QA and the concrete world of QC. Our approach allows us to ensure that we get the opportunity to think about customers and their needs, while we still provide results that are needed on day to day engineering projects.

Our teams certainly work with Software Engineers in QA and QC roles, but we also work with teams to ensure that a product is testable, that it is adequately unit tested, and that it can be automated even further in our teams. We often review design documents and ask for more test hooks in a project, and we implement mock objects and servers to help developers with their unit testing and to allow our teams to test components individually.

We put an emphasis on building automated tests so that we can let people do what people are good at, and have computers do what computers are good at. That doesn’t mean that we never do manual testing, but instead that we do the “right” amount of manual testing with more human-oriented focus (e.g. exploratory testing), and we try to ensure that we never do repetitive manual testing.

The difference between QA, QC, and Test Engineering

If this post interested you, you should check out the positions open at my company in Seattle, WA. We have a White Box QA/SDET position, Black Box QA, and Java Developer positions available.