In my last post about Integrationtest-driven development/Test-driven integration I was talking how to get started with integration testing. Sometimes it comes to the point, where your integration tests need more than only a database and a running system: You have additional dependencies like EJB’s or Web-Services. What now? You can’t always rely on test-systems: Sometimes there aren’t any or only shared instances exist. Sometimes it’s even harder to simulate a specific scenario using real services because of data and logic dependencies.
Blog
-
Integrationtest-driven development/Testdriven integration
TDD (test-driven development) is a well known development process for now. You start with a idea of a solution and the test. Then you proceed within a cycle of writing production code, then test code again, start over.
-
Treat your code: Avoid code bloating in JUnit Tests when using Mocking
JUnit test are inherent to almost every professional Java project. Some utilize JUnit more than others, some use it for integration tests. But nearly all of them have similar issues. As soon as they reach the testing boundaries, they have either to take care of expensive test setups or rely on some infrastructure stuff such as databases or remote services. One way is truly keep going on with the known procedure. A different approach is the usage of test dummies. Either as stubs (i.e. sub classing to simulate the desired behavior) or mocking. Mocks are instances of your classes or interfaces which can be told how to behave in a certain scenario.
-
It’s evolution
In the early days of development, where technical approaches and feasibilities were depending on “is there any solution available”, lots were happy connecting a database using a web front end. Decoupling and abstraction layers were built to hide the complex persistence API. Ugly web wrappers were also tried to decouple. In the end, you got lots of framework stuff, just because there wasn’t anything else.
Today it evolved. Spring hides and provides lots of functionality. Enterprise Java provides API’s for nearly everything that modern applications use: Persistence, Web control, Web-Services. But somehow, thinking did not change much since then. Today we see tons of mappings, abstractions and decoupling layers. Is it really necessary to build data access objects in case you use JPA? Do you need mappings and tons of layers for exposing database data using a REST API?
It’s worth rethinking. Just because we always did isn’t the right answer.
-
MongoDB Sharding and Replication
MongoDB is known for its easy and near zeroconf setup. But when it comes to the point, to setup a sharded cluster with replication, things can get complex. Therefore I’d like to provide a configuration tooling to setup such a cluster with only a couple of simple commands.
-
Controlling Christmas Lights using Midi
Some time ago I’ve posted how to control a relay using Midi. This was a preparation to the christmas lights midi-control. Now let’s see, how it works.
-
Controlling a relay via Midi
Some time ago, I’ve used an USB-based relay to control a XFD (extreme feedback device). Now, let’g go a step beyond that and let a relay dance.
-
Building a health check page
ThoughtWorks recommends it, Ops love it and even you won’t ever miss it: health check pages. Do you really know at one sight, what’s the state of your application? Do you know, where to find your monitoring? Can you find it just in time of an incident?
-
IT Security and SOA-Governance: The Service-Authority
Do you SOA? In case you do, how do you manage IT Security within a massively distributed landscape? In one of my recent projects we met lots of services and the challenge of IT security: Authentication and Authorization.
-
3 years agile: A look back
I’m working for 3 years now with an agile approach. Before that, it was either sort of waterfall or a complete mess. The first agile steps were as well sort of agile but not the real one.
My experience is, that the way my current team is working, is real agile for about a year now. Before that, it was a try and error from which we learned a lot.
(more…)