Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I'll sum up the topics we've dealt with and draw some conclusions. (more...)

Filed under Architecture, Java, Monitoring, Performance, Process, Quality Assurance, Requirements Management, Testing, Tools | No Comments »

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...)

Filed under Deployment, JBoss, Java, Maven, Middleware, TDD, Testing, Virtualization, Xebia Labs | 2 Comments »

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...)

Filed under Deployment, Java, Maven, Middleware, TDD, Testing, Virtualization, Xebia Labs | No Comments »

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...)

Filed under Deployment, Java, Maven, Middleware, TDD, Testing, Virtualization, Xebia Labs, websphere | 3 Comments »

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...)

Tags: mocking, testability
Filed under Java, TDD, Testing | 5 Comments »

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...)

Filed under Frameworks, Java, TDD, Testing | 13 Comments »

Nowadays paired programming concept is getting more and more common in the IT industry because of its benefits like design quality, overcoming difficult problems and better time management etc. Similarly a new concept of Paired Testing is getting famous now among the testers who are working in an agile environment. This concept of testing is similar to paired programming approach. In this approach the person doing the testing is called the driver while the other suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, observes or reviews etc.
(more...)

Filed under Testing | 2 Comments »

I joined Xebia India as a tester for one of the project. While validating the defects the biggest problem that I faced was regarding the understanding of defect report and trying to reproduce the said problem when there were no steps. Being a new member to the team and joining the application in between the sprints added to it. Every time when I had to validate the defect and steps to reproduce were not there I had to run to the developer for their help. Developers too were tied up with their own tight schedules and sometimes the validation for the defect had to wait for sometime which created a backlog for me and then I thought to come up with the solution to it which I am discussing below. Using the following approach helped us and can help all.
(more...)

Filed under Architecture, Testing | 2 Comments »

Last week I ran into a problem while testing AjaxBehavior in Wicket.

Consider the following scenario: we have a FormComponent which has an AjaxBehavior added to it. We want to test that behavior. Depending on the selected value of for instance a RadioChoice, the Ajaxbehavior should show one component and hide another.

You would think that this would be out of the box behavior when using WicketTester, but unfortunately this is not the case. Triggering an Ajaxbehavior is easy using WicketTester, but setting the selected value isn't. (more...)

Filed under Ajax, Java, Testing, Wicket | 1 Comment »

Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.

Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.

At a popular web shop I had the following challenge: (more...)

Tags: Java, Performance, Quality Assurance
Filed under Agile, Architecture, Java, Performance, Quality Assurance, Testing | No Comments »