Posted by Michaël van Leeuwen just before lunchtime: August 10th, 2011
When working on a mobile Android application, I was confronted with the fact that the backend server wasn’t available yet to deliver the REST service. But I needed a server or good dummy for testing the Android client against the REST services. So I began my search for a REST mock server.
I started out using the SoapUI REST functionality, but that still lacks a good implementation for my purpose of reacting on REST calls. I ended up with a 10-minute build-your-own REST mock using the Play framework. This blogs describes how this was accomplished.
Posted by Maarten Winkels in the early evening: June 23rd, 2011
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.
(more…)
Posted by Geert Bossuyt around lunchtime: September 30th, 2010
The tester is a member of a Scrum team. This is a different mindset from the traditional views on testers in software development. The agile tester focuses on delivering value instead of on testing. The agile tester is responsible for delivering what the business needs instead of just finding bugs. Most importantly: the agile tester is not responsible for testing!
Recently I published an article on testing in a Scrum team for the Eurostar 2010 newsletters. It’s about the mindset of an Agile tester. This blog post summarizes the core of that article.
Posted by Andrew Phillips in the early evening: July 21st, 2009
Recently, I was writing an Annotation Processor for the @Composite project. In good TDD fashion, that first and foremost meant writing some tests.
Although I in the end come across something that was fairly workable, it was trickier than one might have hoped for.
Posted by Jeroen Borgers at around evening time: June 29th, 2009
Last time I blogged about the importance of benchmarking the architecture and new technology in a Proof of Concept for Performance. This time I’ll deal with the importance of representative performance testing.
Slowness of applications in development environments is often neglected with the rationale that faster hardware in the production environment will solve this problem. However, whether this is really true can only be predicted with a test on a representative environment and in a representative way. In such an environment, there needs to be more representative than just the hardware.
(more…)
Posted by Cirilo Wortel around lunchtime: April 23rd, 2009
Recently I was challenged by a client to test a new web application in an Agile project. The team was new at working Agile and even more with working together with a functional tester, altogether this resulted in me getting very little development support from the team.
Because the lack of tooling and support I focussed my efforts on just recording test-scripts using Selenium IDE, hoping I would be able to reuse them once I got the development support I had been requesting. The plan was to integrate the pre-recorded scripts in a more extended test environment in a later stage of the project.
Posted by Erik Pragt around lunchtime: May 4th, 2008
Currenttly, I’m in the process of building a Grails application. While I’ve built several prototypes/quick hacks, this is actually the first ‘real’ application I’m building. “So”, I thought, “if this is a real application, I’m in need of some real tests!”. When you’re in the normal flow of developing a Grails application, everything goes so fast, you almost forget about writing the tests. So I decided to do it a bit differently, and do it just like in Java: do it TDD!
(more…)