In my last company, we were maintaining around 8 applications, the testing was becoming complex day by day due to the complexity of creating stubs. We used Java and MongoDB to create mocks. We also used velocity templates for some dynamic decisions. We somehow survived to 3 years. And later on, we moved to stubby4j. It was really helpful, easy to maintain and understand.
However, with the time, we started missing a few basic things in stubby4j. Unfortunately, it was my turn to work on the rest of the simulators. I spent more than 2 weeks and couldn't manage the stubs even with stubby4j. After 2 weeks on 4th March 2016, I attempted to write a utility in NodeJs similar to stubby4j. And I named it StubbyDB and renamed it to Stubmatic later. It not only solved the problem of our project but inspired other projects too to use it.
Problems solved by the Stubby4j 1. Almost no programming. So good for QAs 2. Very less CPU and Memory Utilization. 3. Easy to understand 4. Direct request response mapping.
Here are some reasons why my team of 24 members accepted Stubmatic over Stubby4j. 1. All the features of Stubby4j 2. Multiple mapping files 3. Almost no configuration 4. Dynamic response 5. Response skeleton 6. Request debugging
We reduced the size of stubs by 60%. And looking into the mappings were enough to find and understand any stub.Stubmatic #Node.js #MockedWebServices