Posted by Maarten Winkels in the early morning: September 21st, 2011
Wouldn’t it be sweet if your whole life were perfect? Your wife would fulfill your every wish. Your children would be perfect examples of responsible happy people growing up. At work your colleagues are the nicest people and working with them is always fun. Your team would feel responsible for every action they (proactively) take and the software systems you produce and maintain are flawless and run like well oiled machines?…
You need to wake up! Nothing will ever be perfect and Agile knows it!
(more…)
Posted by Age Mooij in the late afternoon: February 3rd, 2011
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.
Posted by Vincent Partington in the wee hours: January 7th, 2010
Last year, before the Christmas holidays 
, I described how we do middleware integration testing at XebiaLabs and I described the way we deploy test servlets by wrapping them in WAR and EAR files that get generated on the fly. There is only one thing left to explain; how do we integrate these tests into a continuous build using Maven and VMware?
Running the middleware integration tests
So let’s start with the Maven configuration. As I mentioned in the first blog of this series, the integration tests are recognizable by the fact that the classnames end in Itest. That means they won’t get picked up by the default configuration of the Maven Surefire plugin. And that is fortunate because we don’t always want to run these tests. Firstly they require a very specific test setup (the application server configurations should be in an expected state, see below) and secondly they can take a long time to complete and that would get in the way of the quick turnaround we want from commit builds in our continuous integration system.
(more…)
Posted by Vincent Partington at around evening time: December 14th, 2009
Last week I wrote about the approach we use at XebiaLabs to test the integrations with the different middleware products our Java EE deployment automation product Deployit supports.
The blog finished with the promise that I would discuss how to test that an application can really use the configurations that our middleware integrations (a.k.a. steps) create. But before we delve into that, let us first answer the question as to why we need this. If the code can configure a datasource without the application server, it must be OK for an application to use it, right? Well, not always. While WebSphere and WebLogic contain some functionality to test the connection to the database and thereby verify whether the datasource has been configured correctly, this functionality is not available for other configurations such as JMS settings. And JBoss has no such functionality at all. So the question is: how can we prove that an application can really work with the configurations created by our steps?
(more…)
Posted by Vincent Partington at around evening time: December 7th, 2009
For Deployit, XebiaLabs’ automated deployment product for Java EE applications, we are always building and modifying integrations with middleware systems such as IBM WebSphere, Oracle WebLogic and the JBoss application server. These integrations are small enough so that they can be rearranged to get many different deployment scenarios. A typical step, as we call these integrations, would be “Create WebSphere datasource” or “Restart WebLogic Server”. So how do the test that code?
We’ve had some success using FitNesse and VMware to do integration tests on our deployment scenarios. But there were a few problems with this apporach:
- We could only test complete deployment scenarios in this way. If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it.
- Because FitNesse does not provide any feedback while a test is running and the steps, let alone the deployment scenarios, can sometimes take a while to execute, there was little feedback on the progress.
- While it is possible to debug a FitNesse Fixture using Eclipse the process is not very convenient when debugging a technical component such as this step.
- To verify that a deployment scenario has executed succesfully we had to extend our FitNesse Fixture often. And while debugging code under test in FitNesse is complicated enough, debugging a Fixture is even harder!
Clearly we needed a different approach if we wanted to develop new steps easily.
(more…)
Posted by Andrew Phillips mid-morning: December 6th, 2009
Static calls, final classes, objects created in test code: there are few things some of the current mocking frameworks cannot handle. Using powerful approaches like bytecode instrumentation or custom class loaders, these libraries make code that was previously a ‘no go’ area amenable to unit testing. This, moreover, in an elegant and convenient manner that will feel familiar to developers used to ‘standard’ mocking frameworks.
The question is: does such power perhaps come with hidden dangers? Might it be possible that the ability to test more could actually result in less code quality?
(more…)
Posted by Andrew Phillips around lunchtime: November 26th, 2009
Some while back I was preparing a presentation on mocking and testing frameworks for Java. As part of the aim was to demonstrate some real, running code, I ended up spending quite some time copying, pasting, extending and correcting various examples gleaned from readmes, Javadoc, Wiki pages and blog posts. Since then, this codebase has been extended with various new features I’ve come across, and I’ve often referred to it for experiments, as a helpful reference, and suchlike.
I imagine this kind of “live” reference could also be useful to others, so I thought I’d share it. (more…)
Posted by Iwein Fuld mid-afternoon: November 3rd, 2009
Concurrent testing is hard, but not as hard as you think. If you use the right tricks it can be done. This blog shows you one particular trick that uses a latch and a mock to ensure a test scenario is completed before running the verifications.
While working on Spring Integration in Action, I experimented with a neat solution for concurrent tests. When I showed it to some colleagues I was pleasantly surprised by the reaction that I got. Judge for yourself if it’s worth the blog.
The main idea is to use a latch and let your mock count it down. It sounds trivial (and to be honest it is).
(more…)
Posted by Saket Vishal in the early morning: December 22nd, 2008
PHP is becoming better day by day. As I proceed in my path of catching up with recent developments in PHP, I see more and more of adaption in PHP from JEE(Java Enterprise Edition) world. To begin with, I stumbled upon the unit testing framework PHPUnit. The amount of familiarity with the J2EE world is simply amazing.
(more…)
Posted by ShriKant Vashishtha mid-afternoon: May 1st, 2008
Sometimes back there was an interesting debate between Agile manifesto founder member Bob Martin and renowned Jim Coplien about the relevance of good design principles in TDD based development.
Jim had very thought provoking views about what people do in the name of TDD and when it leads to something where it’s just impossible to do any kind of refactoring further as there was no overall sound design/architecture base.
It leads to following questions:
- While practicing TDD and Scrum, is it really possible to focus on a good design considering we just focus on the prioritized list of requirements and don’t really see their interactions with other user stories to begin with?
- Without having a big picture in shape of logical diagram, class diagrams (read UML), deployment diagrams, is it really possible to create a good architecture/design? May be it’s possible in small scale projects where the level of complexity in terms of business logic is not too high. But the question is more relevant for big projects (1-2 million LOC).
There were some interesting follow up in this respect from various people in Xebia. I thought it’ll be a good idea to combine all those thoughts through this blog.