Image for post
Image for post

Just a couple of days back, Vivek and I came across a difference of opinion while planning the testing strategy for a project. The project in question was a Spring Boot based web application. As we all know, Spring provides a Model-View-Controller architecture to develop flexible and extensible web components. From initial analysis we found that, the project was quite structured and the multiple layers were easily discernible; and WITHOUT a single Unit Test. We started discussing the plethora of test components provided by Spring for different layers.

As is with the MVC architecture, the controllers are the API gateways and are supposed to forward the request to the service layer (which is solely responsible for business logic). I suggested Vivek that we start our tests with the controller layer. The classic approach, you know. Take an API, see what all functions it hits in the service layer and write tests for them. …


Image for post
Image for post
To be in a live in, or not to be!

There has been a monumental shift of paradigm from manual to automation with respect to testing a software application. With that, there has been an implicit need for automation frameworks. Conventionally, the popular school of thought has been to maintain 2 separate code bases — development and automation. Developers maintain the former while SDETs look into the latter. Theoretically, it sounds quite apt. A clear demarcation of roles and responsibilities and separation of concerns.

I too was following this norm up till now. Over time I have realised that merging your automation framework with application code is quite beneficiary. To be more specific, all kinds of tests (Unit, Functional, Integration, Regression and even UI tests) can be, and should be, accommodated under the same project as separate modules. …