Hard Mock Cafe

Writing integration tests is not an easy task. Besides the business complexity, it is also often not easy to set up a suitable test scenario. This article will show an easy way to write integration tests for common problems in Eclipse based client-server projects. It started in a meeting with project management. The leader of a large-scale SmartClient project asked: "How come we have so many unit tests, but only a few integration tests?". I guess the main problem was that the application was based on large, interweaved (host) database tables, and we were not allowed to alter any data...even in the test environment. So in fact, we could not set up any test data, we were forced to set up our test cases on the existing data. But it was living data, and so it was subject to change. Means: even if you had set up a test based on that data, it was very expensive to maintain. The project leader claimed: "We need a kind of integration test that is easy to write, needs no maintena

This is the second part of a two-part article on Ping. The first part gave you an instroduction to the Riena Ping API. This second part will show you the usage of the Sonar UI to run ping tests. The first intention was to use ping for automated, JUnit -driven, integration tests. But that did not work out for two reasons: The build server supposed to run the tests was a unix system, but the client was targeted for windows. The build server was located in the intranet and was not allowed to connect to the application server. During discussion of these problems, one of the infrastructure guys said: "Wouldn't it be cool, if we could use those ping tests as part of our daily system check?" Bingo! That's the idea. Instead of preparing a client-like test setup, just integrate the tests into the client. And that's what Sonar is all about: A UI dedicated for running ping tests, that could be easily integrated into any ( Riena -based) client product: No need to say that it

Javadoc is quite helpful if you have to deal with a new API. It explains what methods are doing, and the role each class is playing. But let's be honest: How many times have you ever read the javadoc upfront? After studying some basic examples I usually choose classes and methods by name: Hey, this sounds like the functionality I need. Then I check the javadoc to make sure that it actually is what I want. But this requires that names are well chosen... Bad names do not communicate a method's purpose or, even worse, they communicate the wrong intention. So what are the reasons for poor naming? Well, one reason is for sure careless naming. The one who designs an API knows exactly what it does, so, with a certain lack of sense, he won't even recognize that it's badly named. Another reason is refactoring or redesign that changed the intention of a method. Means: the name was wisely choosen in the first place, but after changing the methods semantics, the name has not been

Data containers like Vectors and Hashtable are part of Java from the very early beginning. The problem is that they are bags for arbitrary data, means the type of data they deal with, is the overall super class Object. That's no problem if you store values, but on retrieval you need to now the type you put in and cast it back to the original type. Then Generics had been introduced, and all collection classes were refactored to be usable in a type-safe manner. You were now able to restrict the collection to one (or, in the case of maps two) types, and the number of cast reduced dramatically. But sometimes you need a container for arbitrary data. Typical usage scenarios for this are context- or configuration-data. An example for that would be OSGi's BundleContext.registerService() method, which uses an untyped Dictionary to provide config data. So the one who provides, and the other who consumes the data, need to know about the type of each date. This is usually some kind of co