Should a newbie in Test Automation learn the core underlying framework?

Question

I am a complete beginner in Test Automation. I am trying to learn Selenium Webdriver with Java, TestNG, Cucumber(BDD) framework, Build tools like Maven.

Now, the problem is that there is an existing underlying Automation Framework that is built in java by some developer guy. It uses Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes, etc. Any team can use this underlying core framework and then start writing the functional scripting code on it.

Now, I am using the POM model to create classes of my webpages and writing test methods in Test Class, which is fine, but I don't understand the underlying framework which is quite complex for me(as I'm new to java as well).

So, can you give some advice on how to really learn the framework from scratch as it looks like a daunting task to me?

Answer 1

You could try developing your own framework for a small demo site.

Start small, add stuff when you need them. Take the existing framework as a model to look up to, but don't sweat if you don't understand everything yet. Be patient and try to understand one bit of it at a time.

Answer 2

Reflection API, has all utilities like ExcelReader Utility class, DB connector classes, Reporting utility, logging classes etc

For starters, based on what you described, this is not a framework. This is a library with multiple responsibilities.

The easiest way to know the difference is:

Your code calls libraries. Frameworks call your code.

As examples of frameworks, you can take Ruby on Rails or Spring and analyse the lifetime of their objects.

For more details, you can check this article or deep dive in the C2 wiki.

the underlying framework which is quite complex for me

One thing that you can do is to break down this fat library into single responsibility libraries, then you can understand the components that serve to fulfill a single mission.

For each responsibility:

• Create a new library;
• Import this new library into the fat library;
• Extract the components related to the responsibility into the new library, running the tests on both sides to check for regression;
• In the end, refactor the tests on the fat library side so it won't depend directly on the new library.