DEV Community

Jorge
Jorge

Posted on

Principles and Philosophies Part 1

I started my career about 9 years ago, the sole Web UI automation developer, using Selenium (Java), automating tests for insurance forms of a homeowners insurance company. I lucked out in that I was given the time to read, think, and experiment to come up with principles and philosophies that have held true to this day.

EVERYTHING IS A TRADEOFF/BEST PRACTICES CAN BE RELATIVE

Understanding what your tradeoffs are will go a long way to knowing how/why you're using the right tool for the job as well as identifying when a better tool can be used. Also understanding when to use Best Practices and the reason for when you should not means you truly understand what you're trying to solve with your programming.
I believe these points are extremely important to being a good problem solver/developer.

Tests should be READABLE

The easier it is to read a test, the faster and easier it is to understand what a test is doing, if you ever need to. This is helped by many things, but Encapsulation in particular helps with hiding technical details behind easy to understand names. Behavior Driven Development (BDD), in my opinion, seems to be the current epitome of creating readable tests, but there are tradeoffs and stipulations that I don't think many really take into consideration, and it ends up being more trouble than it's worth. In any case, the concept of Page Objects[1][2] is encapsulation for UI components and their functionality that can be tremendously expanded on. This and more is used in order to write readable tests, the benefits are immediate and can be read for themselves.

Tests should be EFFICIENT

From a Selenium/Appium perspective, this means avoid using sleeps (without an explicit and detailed explanation for why you need to) and Implicit Waits, which applies an unecessary blanket wait for elements to appear, unless you're dealing with a strictly static website. Referring to the my first principle, there are certainly times when you would use these things, but they're usually used as a way to slow down automation indiscriminately and without understanding, which makes your tests very inefficient.

I hope to make this a series of posts to finally write these thoughts down.

Top comments (0)