I’m trying to get a pulse on how other people do testing with a service oriented architecture. The part that I’m interested in is how are people currently testing the interactions between systems and what have been some pain points in the method that you chose.
For example, on a project I am working on the decision was made to require the different components to be running in order to run some of the tests that ensure that they are working together. This is nice because you are actually testing that the two work together but it makes running the tests a lot slower and cumbersome because you have to ensure the different pieces are up and running. Other ways that i’ve seen testing done is to create mock services that can be swapped out in the test environments to emulate what the remote service would do. This seems like a good way to keep the different components separate but seems to add extra overhead to make sure the interfaces are all in-sync and maintaining both the mocked version and the live version can sometimes lead to logical inconsistencies between the two.
That’s an interesting approach however I think you loose one extremely valuable asset you get when writing different apps, you loose the ability to use the tools that work best for the job. You are forced into a rails monoculture which for larger projects this can actually be a bad thing. On the current project I am working on we have a number of different languages (go, clojure, rails, java, storm). These languages/frameworks weren’t picked at random they were chosen because they provided some non-trivial benefit over ruby and rails that allows us to build the service much more efficiently.
I feel that another downside of going the engine approach is that it becomes harder to individually scale pieces. If I have a one service that gets 1M requests per day and another that gets 1B requests per day, they are coupled in the sense that they necessarily need to be scaled at the same time.
To me it almost feels like using engines is basically the same as building a monolithic rails app but you are namespacing the pieces. It may be easier to test but I think you sacrifice more in the process.
Oh interesting I missed that. Certainly makes testing interruptions between rails services easier, but not really generalizable to heterogeneous architectures unless you were to write mock services as other rails engines but that seems like overkill and has the same risk to becoming out of sync with external services.