Web Element Locator Strategies: CSS Selectors

CSS Selectors have been favored over XPaths for two main reasons: simplicity and speed, though I doubt both. I usually go with XPath. Any element on a Web page can be uniquely located using XPath, and I find XPaths the strongest locator type.

CSS Selectors are not powerful, but most web developers already know how to use them. They cannot uniquely identify any given element on the page. CSS Selectors can never select elements by text context, and they cannot always select elements by index.

CSS Selectors are expressions that use pattern matching to find elements on a webpage.

Because I have abandoned CSS selectors, now I took the time to play with it more, and this is rather a memo to myself.

Continue reading Web Element Locator Strategies: CSS Selectors

Code Coverage. 100%

The question ‘do we really need to test constructors?‘ led me to understand that what 100% code coverage means and why we should strive for it.

Previously I’d always stated that it’s impossible to achieve 100% code coverage. Because 100% coverage means 100% coverage of that you believe to be the system’s functional paths. In other words: it is not 100% in reality. And it’s highly likely to people would write useless tests to reach that 100%.

Continue reading Code Coverage. 100%

it() Should Not Start with Should

Jasmine is a behavior-driven development framework for testing JavaScript code. This framework provides it() blocks to define test cases.

Every it() block contains two parts: description and return call.

description: this is a description of the test case

return call: this block contains function(), it may also have a variable in it, basically this variable will have some set time for to set the total time for the it() block to get executed. You can use it without time as well.

There are many articles, tips and tricks available explaining the best practices and lessons learned.

And this is where I can see that in lots of cases when the description in the it() block starts with the word should.

Continue reading it() Should Not Start with Should

Oh, Marionette, My Dear

When I was running a UI test locally I encountered this in the log file:

[exec] INFO: Retrying request to {}->http://localhost:14804
[exec] Jul 30, 2018 10:17:34 AM org.apache.http.impl.execchain.RetryExec execute
[exec] INFO: I/O exception (java.net.BindException) caught when processing request to {}->http://localhost:14804: Address already in use: connect

Sometimes even the was hung and the browser was closed after a while. So basically I couldn’t execute a single UI test locally that frustrated me.

I will say a few words about the environment I work with. “There is no use saving it until later.” (To use the words of  Richard Brautigan’s words, which is a favorite sentence of mine from ‘In Watermelon Sugar’.)

The test framework I work with is based on top of Selenium Webdriver, it is an extra layer – please don’t ask why. The implementation of this framework is done by another team. Details are overspread, so a lot of digging required if I want something to know.

Spoiler alert!
This framework is launching Firefox 52 by default.

Continue reading Oh, Marionette, My Dear

Quarantining failing tests is similar to death sentence

There may be times when you want to prevent a failing test from causing the whole build to fail so you put failing tests into quarantine.
You have the assumption that when you have time, you’ll fix up those failing tests. Or someone else will do it.

The reality shows a different picture.

Why are tests quarantined?
Tests can end up in quarantine when it is thought to be flaky for example, or a part of the component is being rewritten which is still in progress so that tests would fail, yet the code has to be merged in, etc.

Continue reading Quarantining failing tests is similar to death sentence