A couple months ago, the team, I work on, introduced integration tests. Before that, we had only regular Unit tests, which ran in a very isolated environment. You do not have a control, how your modules behave when they interact in a real environment. You cannot test a lifecycle with persistence to be confident, because you need much more than mocks.

Now it's 6 years ago, since I started to apply Clean Code Development (CCD). For me it's today way more than clean-code-developer.com. It became a system of values, based on best practices, principles and a set of pragmatism.

Recently I reported about Clean Code Development. Everybody who's visiting trainings, courses and sessions is amazed. It's easy, most topics are obvious but not everyone is always aware of these topics. But when you look deeper constrained by the big picture there is as well a dark side.

There are days or weeks, you feel, every day something is failing. Crashing systems, strange bugs, ghosts. For some reason you don't know, why this happens, over and over. But you are the man in the middle. You're the one, having all those dependencies. Then you have to fix it.

All the developers I know, recieve a mass of Mail - JIRA updates, Commit-Mails, daily mails and sometimes a notification from your Build system about broken builds. This notification mails could easily be overseen. However overseeing or disregarding the notification about broken builds is very detrimental because the notification helps to prevent bugs and increase quality. And could you imagine, what happens, when a broken build has to be released? For sure, it will cause lots of effort.

With modern Tooling it's easy, to Mock a WebService - take your Service-Class, inject Mocks (for your dependencies) and tell the Mocks how to behave. The next usual Stage is Integration testing. That one can become hard, you have to rely on remote services. Once the remote service is down, you even can't test the webService remoting. Does the stack behave in the right way? How about the WSDL? Is it right?

In my last post, Unit-Testing of Web-Services with JUnit - SOAP Services, I've demonstrated how you can test local SOAP Services with remoting in a local Unit-Test. But since SOAP service become more and more unpopular, there might be a different technique. Currently REST becomes the name of the game. So let's take a look at JUnit testing RESTful services with remoting.

Can you tell me this pirate's riddle solution? These pirates are used to live in the indian/pacific ocean. If you find the answer, post how long it took you, which tools you used and how many steps it were on Google plus.

I want to give you a better insight in Clean Code. Therefore i created a bunch of code lines with examples. These show you a set of good/bad (after/before) scenarios. You can find these at GitHub:

https://github.com/mp911de/CCD

Roy T. Fielding wrote and described REST in his dissertation in the 2000's. He basically told about the an architectural pattern and mapped it to most common protocol: HTTP

Since these days the IT community began to realize and to understand more and more what it means to deal with resources, what power and strength HTTP provides. But what's so special about it? And why does everybody talk about it but the least understood it? Why is today everything called REST, but in fact it's not REST? Let's dig into it.