It’s a trend to Brake up the Monolith and use modern architectures and micro services.

If you read this article you might be the situation when your team decided to brake up the monolith and of course you’ll have to follow them. Or you have a huge codebase automation projects which is holding 5+ projects and all the things are getting really messy for you.

Let me tell you my recent experience . Our monolith codebase is holding 7 projects in one codebase. All projects are around the same thing just a different skin and few custom functionalities . From Testing perspective we saw it really cool as we setup one framework common steps and page objects and just handle the custom things with some if/else.

Everything was good until devs started to brake up the monolith and our all in one integrated framework was very hard to maintain and there was too many things to consider in one single place.

Time for a change, Brake up the monolith

We decided to brake our big cucumber – capybara projects into small little projects. There are plenty of things which are still common for most of the projects but there are plenty of them which makes the projects different , so we had to please everyone here.

We decided to do as bellow :

Create one gem package where we move all common cucumber steps together with the page objects. Everything got into a small library which everyone who needs any common steps can inject the library into their project.

Create one single configuration package which is going to deal with all setup related things.

Create one generic package for helpers. All generic helpers went into a small package which everyone can use.

Create one driver factory package which everyone will have to inject it into their project and just call MainInstance.init_browser into their env.rb file.

As we run our tests dockerized we had to make our groovy code reusable , so we went for a groovy qa library . You can find out more about the shared libraries here.

Create one generic api library to be injects in all api projects .

And thats it . Simple isn’t it ? Sound like it but I’m telling you we are still working on it . It’s a long way to go but its a must .

Why we did this ?

As the big monolith project is getting sliced up for those projects which are already independent from the big code we can run CI and CD without over-testing.

Over testing ? WTF !?

Yeah , over testing ! Monolith was getting build and we didn’t knew where the change was , I mean we could not find out so we were running plenty of tests just to make sure stuff doesn’t brake , which means over testing . Now we have small project exactly on the target.

And what now ?

Now we have small projects which each team can maintain separated , we’ve got a QA team which contributes to our own internal libraries and we still get to work together also one of the most important things from this step is that we still get to reuse every single bit of the monolith code.

Tell me about your projects , do you have a similar situation ? Or how would you do it if you’d be me ?

The end , Happy testing!

The post Brake up the monolith appeared first on Testingrepository - Testing repository - selenium webdriver solution and more.