Testing

Robotium: black-box testing for Android apps

Arno den Hond

As pointed out in an earlier post the importance of testing can not be understated.
In this post we will delve into BDD of Android apps.
There are a number of other testing tools for Android out there, such as Robolectric and Calculon. Robolectric improves the speed of running the test by executing it outside of the emulator. Calculon is a DSL for testing views and activities. As Robotium seems to most mature and reliable, it is my preference.

Robotium.org

 Read more

Writing and testing data structures and algorithms in JavaScript

Maarten Winkels

Tonight in one of our knowledge exchange sessions, one of my colleagues challenged us to writing a TagCloud in JavaScript. He had prepared a nice setup with a server producing twitter hashtags over a WebSocket to the browser and using Processing.js to produce a graphical representation of the tags zooming by on twitter. Since he had already done all the heavy lifting in integrating all these fancy new frameworks, what was left to do, you might ask. Well, we still needed to implement the algorithm to count the number of tags on the continuous stream, sorting this list on the bases of the counts and making sure the system wouldn't run out of memory by removing less used tags in some smart way. His point to all of this was, that although JavaScript is being prophesized in some circles as the new-old-new language of the future, writing and testing a non-trivial algorithm in it is a big challenge.
 Read more

What happened to the Open Source performance monitoring and analysis tools

Mark Bakker

In my current position as Performance Engineer and in my past position as a Middleware Architect I did quite some work with closed source performance monitoring and analysis tools (i.g. CA Wily and later AppDynamics).
These tools are both expensive but also do quite a good job most of the times. In the same field there are more tools, but all in the same price range for as far as I know.
To name some: Foglight, Dynatrace, Newrelic, JXInsight, Tivoli Performance Viewer, Compuware Gomez.

Around 2006 several initiatives to create open source performance monitoring tools for java production environments started to appear.

This was mainly because AOP (Aspect Oriented Programming), the technology used in most of these products, was getting attention in the market and there were quite some developments in that area at the time.

I am interested to see how the open source community around these kind of products is evolving. The outcome is quite surprising…

 Read more

Get your webtests in FitNesse with Xebium

Arjan Molenaar

In the first installment on Xebium, Cirilo explained the ideas behind this FitNesse fixture:


Xebium creates a simple way to use Selenium IDE (low learning curve) and FitNesse (ease of maintenance) to it's fullest when it comes to maintaining a web application test suites.

Xebium is using the same keywords as Selenium IDE. This has the huge advantage that no person should learn another DSL. Since tests are stated this way, they can be copied between Selenium IDE and FitNesse without a hassle (the FitNesse formatter for Selenium IDE is rather trivial). And to be honest: as long as there are XPath and Regular Expressions in the code, it makes no sense to come up with a substitute for verifyText.

 Read more

Introduction to Xebium

Cirilo Wortel

Introduction

When testing web interfaces, it’s convenient to use an intuitive tool like Selenium IDE, it’s easy to use and can be used by non-technical people, but it is solely meant for record and playback of test-scripts. One of its limitations is that it misses sufficient options for documenting and managing tests. Furthermore it misses an interface with the backend of the system under test (SUT), to setup preconditions for a test or for instance to manipulate or read from a database.
Fitnesse is a great tool to do just that, it has the Wiki to manage tests and it by default has a setup and teardown mechanism, it’s easy to add non invasive testfixtures to interface directly with your SUT. The downside is that it is incapable of doing webtests.

We now have the glue that combines the two, it's called Xebium!

 Read more

iOS + XCode 4 + GHUnit = Mobile TDD+Continuous testing part 2 of n

Robert van Loghem

Last time I explained why I think doing TDD for mobile is imperative, and why I do it. But now it's time to get technical, and explain to you how to set up, GHUnit in XCode 4 and run unit tests, not only in the iPhone and iPad simulator but also on your own physical device!, it's in text and images but also in video form on YouTube.

Note, if you want to know why i chose GHUnit over OCUnit, just scroll down to the end of the post.

 Read more

Why TDD+ Continuous testing is imperative for mobile apps (part 1 of n)

Robert van Loghem

Since a couple of months I've been developing mobile applications, some are for the business at home (girlfriend-shopping-list app that actually works and augmented reality garden iPad app) and some are for work. I have experienced that TDD and Continuous testing (Test Driven Development) is a way of working that leads to fewer bugs and regression problems and better design in my software, it's my preferred way of programming, not testing.

Mobile TDD is imperitive

And to start off, here's how I benefit from doing TDD:

  1. Robust
  2. Better code design, no really!
  3. Find regression problems early on

and you can read more on TDD and Continuous testing here.

The thing is, writing a mobile app takes about 20% of the time it would take me to write a web+client+server based app. Which of-course is really nice, because I can write lots of apps. It also means that whenever i need to fix a bug or add new functionality, I need to have developed it in a TDD fashion, otherwise i cannot guarantee reliability. So let me explain why…

 Read more

Saved by Fitnesse

Jan Vermeir

We've been busy for a couple of weeks now refactoring a fairly complex code base of just under 500 classes. None of us really knew all the details about this part of the system, but we didn't let that stop us of course. After some regrouping/-shuffling/-factoring/*ing, the whole thing built OK and all unit tests were green again. All that was left to do was fix the Fitnesse tests. I remember thinking this should be easy since we had all those green unit test.

Evil laughter sounds.
 Read more

How to Fail at Writing Bad Code

Age Mooij

Trying to produce bad quality code is quite hard when you are using Test Driven Development (TDD), even when you are doing it wrong on purpose.

Recently Iwein and me were preparing some labs for a developer training and the plan was to create some really bad quality Java code as a starting point. Students would then be asked to clean it up and add some new features, all this of course with the intent to show the effect of bad code quality on your ability to quickly add new features. This was going to be a piece of cake!

After some brainstorming for interesting standalone programming challenges, we came up with the idea of writing a JSON to XML converter. It should be able to take any valid JSON string and convert it into a simple XML representation. Out of habit and without really considering the option of skipping this step, we started with a simple failing test. Here it is:

@Test
public void shouldConvertTopLevelEmptyArray() {
    assertThat(converter.convert("[]"), is("<array></array>"));
}

Simple, right? To implement our converter we decided to use the well known "red, green, as little refactoring as possible" anti-pattern, which we expected to result in lots of copy-paste duplication, very long methods, and the other typical code smells we all know and loath. Our first implementation approach was to go for some all-time favorite candidates for producing bad code: string manipulation and regular expressions. As Jamie Zawinski famously said: "When some people have a problem, they think: 'I know, I'll use regular expressions'. Then they have two problems." We had created a sure thing recipe for disaster. It was going to be all downhill from here, or so we thought.

 Read more

Regression Testing with an Agile Mindset

Maarten Winkels

When applying agile methods to existing software development practices, it is often useful to start from the basics. For regression testing this boils down to:

  1. Regression testing ensures continuity of business functions.
  2. In an agile context it helps the team focus on the (new) functionality to develop in the sprint while maintaining overall stability.
  3. To maximally utilize regression testing in an agile context, test automation and continuous execution should be applied.
  4. It is important to realize the difference between functional tests and regression tests to avoid some common pitfalls.

 Read more