JUnit testing services and clients with javax.xml.ws.Endpoint

Following situation: you have written some generic stub to use in your projects that creates a client for a service. Your client is smart and does some magic for connections (proxy, cache or other kind of magic). Or maybe you just have written a service for that matter. Anyway, you now want to test it. Unit testing the functionality of your methods is a must. But you still want to reach 100% coverage and need to test the service as it would run in real life.

Then you can use the javax.xml.ws.Endpoint class.

If you prefer figuring it out yourself, you can find the code (as a project for netbeans) --here--

To follow the code examples as html click  --here--

So here is how you do it:

If you've coded nothing fancy, then you probably have a class like this:



This is a generic client for opening connections to services. It gives you back a port of the type of your service where you can call your operation as a method of the port. It is very convenient if you have to do some nasty network-connection-recovery-proxy-cache thing, then you just do it once and put it into a library. 

Anyway, now you want to test this class, as is central to all your service calls, you want it to bee 100% fool proof.  You probably already notice where the problem is going to be: Yes there is a static call to javax.xml.ws.Service. Unless you are using PowerMockito or something like that, stubbing static classes is going to be a problem. Furthermore, why making a mock? Although I am a real fan of mocking, in this case I'd rather test the client for real. 

The Idea: the plan here is to create a test service (as simple as possible), start it up before every Unit-Test, create the connection and have the service do what I need for the test. 

So it breaks down into 3 Steps:

Step 1- Create a Web Service

Create a test service, with javax.jws it has become very easy to do so by using annotations. Put it into your Test-Packages, so it does not get mixed up with productive code. This is an echo service which gives you back whatever you put in.




Step 2 - Create a Service Interface

This is the fancy part of your client implementation. By creating Service-Interfaces you can use generics to use the same code for creating clients and cast it to the Service you are using.



Step 3 - Test It

In your test class, make a setup and a tearDown method. Use the annotation @Before ans @After respectively.
In your setup method, now you can create a service using the javax.xml.ws.Endpoint class and publish your service implementation. This will create and start an embedded jetty server and publish your service. Don't forget to tear it down afterwards, or the next test won't work because the port is busy. Oh, and think of a port number that is not used in your CI or DEV environment. (By the way, is there any convention to ports you can use for unit testing?)


And there you have it!

You will now be able to use the service in your unit tests. To test exception handling, you could for example pass parameters to your service and have it throw the exceptions. 



Disclaimer

This is not new, I found lots of comprehensive articles about this, the best one form Glen Mazza's Weblog, to which I definitely refer, if you need any other server functionality that is not provided by embedded jetty. I would see any test needing some special tomcat functionality (or from other application servers for that matter) very close to the border to integration tests. But what is a unit test anyway, huh? And 100% are 100%, so if you think it is worth it, you'll need to create a war and deploy it to be able to use it.







Stop the software / car analogy

I can understand that making analogies is a very powerful form of explaining a hard concept, but you should be aware of the demons you might be unleashing. 

I like analogies, as much as anyone. I do the Einstein-Train-Thing to convince my self that I understand relativity like the next man. But everybody is careful talking about relativity and nobody would walk outside the framing without considering it very carefully.

Software on the other hand is not so respected, and I ask you: does the next man really get it?

Everybody can relate to cars, right? So that is a good reason to use the analogy, you would think, but here is where I have to disagree:

Thinking you know about the domain, sells, production lines, marketing, resourcing, electronics, hydraulics and all the engineering that has been put into the car is the first mistake. The second mistake is assuming other people do (unless they work for BMW or something like that). 

You think you are making the software concepts simpler, just by equaling them to something people can relate, but you (if you are a developer) understand the software as an engineer would understand a car (maybe not even all cars, just some models). So you see the way things have to be mapped for your analogy to hold, but by making others think they can too, there is very much harm done. 

People automatically will start solving problems in the car domain, not worrying of the other side of the equation. I see it all the time, they discuss for hours (true story) about the wheels, and colors and sport edition vs. luxury set-up implying there is some high cognitive back-port to the software domain that you originally were talking about. Concepts get all weird and people get very creative and try to illustrate their concepts talking about paper cars, or invisible cars that only exist for one ride (true story again). 

That is simply wrong. Try to elaborate your concepts without the use of analogies, unless you are absolutely positive that  you can defend your framing.

There are of course some examples that work but they work on the bad side of making analogies, i.e. making an obviously far-fetch connection, like: "you buy a car, and some little writing in the ignition says that by turning the key you agree to drive only to a Toyota authorized cinema". This would illustrate very good some software licensing agreements in real life. 

But generally speaking, there are more reasons why software is not like cars. Here are my top 5:
  1. The user experience of software and cars is not the same. You don't drive software. A computer drives it for you.
  2. While costs of developing might be similar in car and software domains, the cost of production of software if mostly 0.
  3. People that reverse-engineer and understand a car, still can not make one.
  4. You can't paint your software blue and sell it as blue-edition.
  5. Try rebooting a crashed car.
Think about this the next time you try to explain your software.

Guide to hiring software developers for your dream team

You want to hire a new developer to support your team, or want to build up a new development team? New trends show how everybody is investing their money in software development. In my opinion, every company today has to do some software (or should), but there are very different ways to go about it. You could have some kind of  project managers supervising an outsourced team in Bangalore or Rio doing your software. If that works for you be happy, but you should be aware that you are not investing in software as in creating value for your company. Your software is costing you like you were leasing a machine. Lots of companies have found out the hard way, that this model does not suffices. Different to leasing a machine, you will not get the new model in 2 years just like that. In order to be competitive in today's market you need to invest in the knowledge that is reflected by your software applications and house them intern. If your company has decided to build up a team of developers for this purpose, I can probably be of some help.

For this article I will assume you are sure you want to build a software application of some sort (or are already developing one or several) but are considering hiring new people. I have been on both sides of the interview table and I would like to share my impressions with you, hoping this might make a better world for both, the developer and you: the manager hiring them.

Here is a list of possible roles for developers in a team. Later I will go into details of how you figure out which one is the one you need. How do you find out the skills of interviewees is a complete different question, that I will try to sort out another day. I do have some tricks and methods I've developed over the years. 

The first thing to do is to be sure of what position you are trying to fill exactly. In order to do that you will need to understand what kinds of developers you will find out there:
 
Lead/Chief developer: the guy who figures out everything before everyone else and has a very strong opinion on how to do things. Of course he is a programmer, not always the orthodox one. He knows all the rules but might choose to break them now and then. He is proficient in lots of languages (computer and natural) and is tough discussing with (needs a whiteboard all the time). Can make points extremely clear and when confronted with facts does not get emotional. He can listen to others too and actively tries to understand the point of view of different people. If you have a classic team of 5 you need one of these on the team. It scales only linear, because this guy does code review for most of your application's software (even if the team members don't notice). 

Application/Software Designer: a visionary. This guy can see the future. No kidding! This is the guy that makes from your software an application by giving it a purpose. He has been an excellent programmer for most of his life, but it was the means to the goal. He has done all: logic, object oriented, functional and procedural programming (I probably left some out). He is not religious about it. He knows that from great software comes great responsibility and stands by his design. He is creative (he probably plays some music instruments or paints).  Depending on the size of your application, you will have one or two of these for redundancy, no more. Don't mix him up with a so-called software architect (see below). He will only be able to take care of a certain amount of software, i.e. an application of  a certain size. After hiring this guy you will be talking mostly to him (if you are the product owner). He will be the first point of contact to your application, knowing things your application could do before you, but also showing you the limits of the current design.

Features/Software developer: senior or junior (depending on experience) you should try to have 5 of these guys in your team. Not everybody is a leader. You need this positions to get the work done. These people understand things fast and are on the border of being obsessive compulsive about The Build. They are masters in unit testing and they all can Linux --no exception. They handle the back log on their own terms and tackle the application one task at the time. They are interested in peer review, resistant to criticism (in the good way) and are excellent team players (which is the tricky part).  Most of these guys would solve the same problem in different ways, just to try something different. They learn fast on their own and would go the extra mile for something they consider to be the coolest solution.

Integration/Test developer: again with experience or junior this guy is not the QA. This is also more a role than a steady position. You will want to keep this rotating among your developers. You need a guy to take care of the difficult parts of testing your application. Some designs get complicated with time and you need a developer that has a clear understanding of the how of the software more than the what (that would be QA). While your normal developers should be able to test the software they write, there is much more to the software than just the sum of its components. This is where this guy comes in: by not having to directly add features to the software he is able to focus on how to test the interaction between components. He creates software to assist the testing of your software. Part of this job is also to look into design concepts and make prototypes together with the designer, figuring out the best way to integrate new ideas into your system.

Software Architect: this is probably the most misleading role of all. An unhappy analogy to construction work in my opinion, but the name stuck around (although in some countries this is an official title and you can not call yourself an architect). For certain size of applications (or complexity) you will need a guy that takes care of putting all things together by enforcing standards and trends. Most companies see this as an overall consultancy job, which in my opinion is not correct. This guy should be in constant dialog with the designers, because he will not be able not follow the developing of the application to the point of understanding every detail. Why you need him then? If your company is big enough to have mixed environments and different teams with different sets of skills, you will need a guy that levels heterogeneity by trying to apply common sense to your system. He would need to have his hands on the software at certain level. He should be capable of doing the things he wants and to enforce them leading by example.

How do you decide who do you need?

If you start from Zero, then it is easy: you will need to hire someone to help you hiring others. This task would be best fitted by a Lead Developer or a Software Designer. In fact, every developer you  hire first will automatically become the lead developer (at least for a while). The difference to a Software Designer will be very small at the beginning, so there is no point arguing about who should be first. For a very small team, this roles are in my opinion interchangeable. This guy can help you defining your application and will be able to refine your ideas and make them into software. He will help you build your team.

If you are already running a team of developers, the task gets more tricky. I'll go by the size of your team. If you have less than 5 members, then first check the roles above to see what you already have. Probably some of the roles overlap. This seems to be a common state out there. Try to pin down the role of the Lead Developer. If you already have one (and are happy with him, if not, this is the guy you are looking for!), then both of you together should consider whether a Designer  is needed yet. This depends on the size of your team and the complexity of your application (or the complicity that you expect in the future). If you feel like you need more hands to do stuff, but cannot tell what way your application is going, you could hire another Application Developer and reconsider the Designer position later on.

If you have a team of 5 or more, you should be looking into structuring it. Again pinpoint your roles and fine out the closest one to the Lead Developer. He should be able to tell you how to divide your application developing into 2 groups. Teams larger than 7 members are hard to handle and not very productive in the software world. You will find it all over the literature about software teams and developing methods like scrum, extreme programming and that kind of agile stuff. That number is mostly based on experience. The upper limit is 10 members, then you will need to split it. At this point you should be looking to hire a Software Designer. Different groups tent to do things different and evolve their own dynamic. The Software Designer is the one that will allow you to synchronize results into a common vision: your application. At this point, the teams will be too big for you to manage directly, and you will have to trust the application developing to the Software Designer and your Lead Developers (yes, one per team).

If it hasn't happen yet, you will need to appoint one of your developers to be Integration Developer. If you don't have the man power, you should be looking for someone to fill this role. In my experience this is a difficult place for anybody to start in a new team, and it becomes very challenging for a Feature Developer to do both things. You don't want to hire an Integration Developer from scratch, because his ramp-up phase would cost your team more productivity than the ramp-up phase you'll need for a Feature Developer that can start small doing pair programming.

The last person you will need, if your application becomes really big, is a Software Architect. You'll be probably be willing to ask around in your team if someone wants to become this before you look to hire one from outside. Unless you are trying to introduce new technologies, techniques or infrastructure for which you could use some experienced outsider (in big companies, this happens more often than you'd think), you will be better off putting a motivated developer, that already knows the application, into that role. You should prepare a plan together with him of how he can work in the necessary skills for this position (seminars, technology certifications, etc), and how to gradually handle over developer tasks his successor.

I based this guide in personal experience and that of friends of mine that were in need of hiring developers into a non typical software domain. I have been a developer in a start-up, a middle sized and a large company, each time dealing with projects but also product development. The hardest thing to understand is that although you can make software like you do other projects (planing, specifying, implementing, blaming), you will by far not be as effective and qualitative as a dedicated team would be. The capital represented by your applications is not the software itself nor its features, but the team that holds the knowledge to do them.

If you do not understand software development it is OK, as long as you understand your team.

I miss Buffy

I can't believe there are so many people out there that never watched the show. It had it all, a super cute star with kick-ass powers and cheap vampires that didn't shine and drunk real blood... Today we were talking about the show in the office, and only one (other than me) was a fan. I was surprised. A nice idea came up though:


  1. wooden stake
  2. silver cross
  3. holy water

Python and Access-Control-Allow-Origin

Ok, here is something that probably happens a lot:

You are trying to do some .js (if not you should get started), and write some code in your favorite ide, save it, load it in your favorite browser and everything is ok. You are a good developer and start making packages and loading your files when you need them: lazy. You don't want to overdo things, and manage to put stuff into a bunch of .js and .html. You load them into your browser and BAM:

Access-Control-Allow-Origin  
Failed to load resource: Resource failed to load  
So now you are all WTF, right? You Google (some would Bing) it and sure enough, what you were thinking is the ugly true and by now you get angry as a bird. Why? Ok, for those that didn't know there is a thing called Same Origin Policy, that forbids you from loading stuff across different domains and bla bla bla... So what does it has to do we you? You sure enough are not trying do load across domains, your are loading a file... you may think, but no. Your file is from a different origin than your loaded page. At this point nearly every post tells you to run a server or allow file access in your browser. The latter is probably a very bad idea if you do actually browse occasionally through the web. So a server.. right... you have lots of them because you are a developer, but you have to configure a lot of stuff to make them point to the right directory.

(Meh.)

But then there is this other way using python:

$ cd WebPageProject/
$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Simple indeed and beautiful.

Release Plan

Mario: is of course the developer trying to save the princess
Princess: is the release
Barrels: are either feature requests or bugs
Hammer: reconsider / won't fix
Kong: release manager

Story: Mario starts at the wrong end. He is actually done developing at the time the release comes into action, but has to run his way up through the plan to make the release on time and help the princess. On the way up, there are all kind of features and bugs rolling down wanting to hurt Mario. He has no possibility whatsoever to get them done faster. However, it is in his power to keep some of them from getting done before he reaches the princess.

ThreadLocal as an Enum - I'm not afraid to admit it!

Well, as disturbing as it might be, I am not afraid to at least admit it: I did not know about the elegance of the following construct:

public enum TLData
{
INSTANCE;
private final ThreadLocal<String> myData
             = new ThreadLocal<String>();
public String getMyData()
{
  return myData.get();
}
public void setMyData(final String myData)
{
  this.myData.set(myData);
}
}


Since you are using an Enum, nobody can create new members from outside, you don't have to care about privatizing any methods and you can access it as easy as:

public class myClass
{
public void myMethod()
{

  /**
     * setting the data
     */
  TLData.INSTANCE.setMyData("some data");

  /**
     * getting the data
     */
  String myData = TLData.INSTANCE.getMyData();
}

}


Isn't that fancy? I had to admit I never thought of it myself. A colleague of mine had to put it under my nose.