TL;DR
automation framework. Here is my answer based on my practical experience through several projects.
I was having a discussion with a few of my QA friends about the advantages of having a test automation framework on the same tech stack as the system under test.
I believe having the same tech stack can help involving developers during code review or discussing technical terms about the code while setting up the framework.
However, my friends think that if there is existing automation using a different framework, it’s a huge overhead to rewrite them in a new framework.
I wanted to know what is your opinion about this?
As being a mentor also helps me to advance my testing craft, here is my answer.
The first rule, developers should write tests in the same language as developed code in Test Driven Development paradigma. The reason is straightforward, TDD helps you to design your system. Tests could come after actual code. When you try to write test code, you will realize that you have missing production code features. For example, a system that handles the situation when the input path could not be opened. Meaningful handling of that information is to inform the user of that feature what actually happened.
The developer could write unit and integration tests, as long those tests do not cross unit boundaries using any of the communication protocols, such as HTTP.
Integration tests over communication protocols such as HTTP should be written in programming language best suited for that purpose. For example, I would develop the browser automation framework in Ruby, not because I am religious about Ruby. The reason is an excellent repository of Ruby libraries (Gems) that resolve problems for me. Cucumber, page-objects, and Watir are excellent examples of browser automation. Ruby strength is more straightforward and less code. Here is one example of how to read an email in Ruby and Java.
Integration tests over communication protocols are software tester responsibility. In that case, they test the system using a black-box approach, exercising it as a user would do over that communication interface.
Comments are closed.