Following on my recent discovery of Selenium Manager, I checked out another project by Boni Garcia called Selenium-Jupiter.

It uses some advanced features of JUnit 5 (aka Junit-Jupiter) to make tests easier to write with less boilerplate code, part of that is using WebDriverManager to automatically instantiate WebDriver instances without downloading chromedriver, putting it in the path, setting webdriver.chrome.driver path in properties or as an environment variable, etc.

It starts with an JUnit 5 Extension — similar to JUnit 4 Runners – but you can have more than one extension.

@ExtendWith(SeleniumJupiter.class)
class MyTest { ... }

Then you can pass a WebDriver instance as a parameter to your test method (without having to create the instance — the Extension takes care of that for you.

@Test
void testWithChrome(ChromeDriver driver) { ... }

Or you can specify a different driver, for example FireFoxDriver, EdgeDriver, SafariDriver, etc.

@Test
void testWithFirefox(FirefoxDriver driver) { ... }

You can also specify whether to conditionally run a test with a specified driver, if docker containers are available, or if a site is up, and many other options available for WebDriverManager.

For instance, run this test only if you’re on a mac

@EnabledIfBrowserAvailable(SAFARI)
@ExtendWith(SeleniumJupiter.class)
class SafariTest {
    @Test
    void testWithSafari(SafariDriver driver) { ... }
}

Or run this test only if your Selenium server is up:

@EnabledIfDriverUrlOnline("http://localhost:4444/")
@ExtendWith(SeleniumJupiter.class)
class RemoteWebDriverTest {
     @Test
     void testRemote(@DriverUrl("http://localhost:4444/") { ... }
}

Or if Appium is running:

@EnabledIfDriverUrlOnline("http://localhost:4723/")
@ExtendWith(SeleniumJupiter.class)
class AppiumTest {
     @Test
     void testMobile(AppiumDriver driver) { ... }
}

So I was working with WebDriverManager this morning and one thing led to another, and I ended up browsing the Selenium source repo (as one does) and saw some curious commits (like these):

mark Selenium Manager implementations as beta

fix the framework conditionals for Selenium Manager

Add Selenium Manager support for Linux & Mac

from an old friend Titus Fortner.

I reached out to ask him about SeleniumManager — and it turns out it’s a replacement for WebDriverManager incorporated into the Selenium codebase (written by Boni Garcia, the original author of WebDriverManager, in Rust).

The various language bindings wrap a Rust binary (which for reasons I didn’t ask can’t be cross compiled with Selenium’s frankenstein 3rd or 4th generation custom build tool) so the SeleniumManager binary is packaged with the source.

Very cool, I thought, and then asked when it’s coming out.

Turns out, it was released today with Selenium 4.6.0

Here’s the official Selenium blog announcement:

Introducing Selenium Manager

Selenium 4.6.0 released

Greg Paskal on the “Craft of Testing” Youtube Channel, talks about the trap of “Going for Green” or writing tests with the aim of making sure they pass.

He has some great points and I recommend the video. Here are my comments from watching his post:

Two big differences I see with writing test automation vs traditional development:

1. Tests will need to be modified frequently — over a long time, not just until it “passes”.

2. Test failures cause friction, so you need to make sure that a failure means something, not just a pass.

What these two principles mean is that a test can’t just “work”. It needs to be able to let you know why it didn’t work — you can’t afford false positives because the cost is ignored tests — not just the failing test, but all others.

With a failing test, knowing why it failed and identifying the root cause (and production system that needs to be fixed to make the test pass) is only half the problem. When functionality, an interface, or some presupposition (data, environment, etc) changes, you need to be able to quickly adapt the test code to the new circumstance, and make sure that it not only works again — but that it is still performing the check intended.

That the test is still testing what you think it’s testing.

These challenges combine to make writing test automation code significantly different than writing most other code.

If you use VMWare vCloudDirector administration tool for managing your virtualization datacenter, you should be aware of the following vulnerability and patch your systems.

“An authenticated, high privileged malicious actor with network access to the VMware Cloud Director tenant or provider may be able to exploit a remote code execution vulnerability to gain access to the server,” VMware said in an advisory.

CVE-2022-22966 has a CVSS score of 9.1 out of 10.

Upgrading to version VMWARE Cloud Director version 10.1.4.1, 10.2.2.3 or 10.3.3 eliminates this vulnerability. The upgrade is hosted for download at kb.vmware.com.

If upgrading to a recommended version is not an option, you may apply this workaround  for CVE-2022-22966 in 9.7, 10.0, 10.1, 10.2 and 10.3

See more details at:

https://kb.vmware.com/s/article/88176

https://thehackernews.com/2022/04/critical-vmware-cloud-director-bug.html

“Are you only interested in test automation?”

I was asked this question casually, and here is my (detailed) response:

My opinion is that test automation serves 3 main purposes:

In each case, the automated tests’ primary roll is making sure the system works as expected and providing rapid, repetitive feedback.  

My opinion is that manual regression tests don’t necessarily make good automated regression tests — and that you can often develop them independently easier.

When I create automated tests, it is usually through the process of exploratory testing and analyzing requirements, and then determine when and whether to automate based on the following criteria:

Is this a check that will need to be done repeatedly?  

(Are the manual setup or verification steps difficult & slow to perform manually, or do they lend themselves easily to automation — e.g. database queries, system configuration, API calls, etc?)

Is this interface (UI or API) going to be stable or rapidly changing ?

(Will you need to frequently update the automation steps?)

Will this test provide enough value to pay the up front cost of developing automation?

(Is it harder to automated than to manually test? Or will it only need tested once?)

The reason I don’t recommend translating manual regression tests into automated tests is because not all these criteria can be met, and also that often, not all of the manual steps need to be reproduced in automation — or automation can do them more efficiently. 

For example: creating accounts via an API, verifying results via a SQL query, or bypassing UI navigation steps via deep linking, setting cookies, etc.

Automation also lends itself well to testing many data variations that are too tedious to perform manually, so you can end up testing some scenarios more thoroughly than you would with manual regression (due to time constraints).  

And sometimes, the cost of automating something is just not worth the effort, and it’s easier to perform manual checks.

All this said, I’m not opposed to doing requirements analysis and manual testing — in fact I consider it an important part of deciding what and how to automate. I just don’t think that automation should be considered a secondary step — because of my initial premise that the goal of automation is to accelerate those other rolls of development, testing, and delivery.

Yet another victory over MacOS!

To stop MacOS from rearranging your virtual desktops (after you have them just the way you want them):

Go to System Preferences > Mission Control
Uncheck “Automatically rearrange Spaces based on most recent use”

Thanks to:
https://www.appsntips.com/learn/how-to-stop-mac-spaces-from-rearranging-themselves-on-macos/

P.S. If virtual desktops (or “Spaces” as Apple calls them) are new to you:

Press “F3” to view your virtual desktops.

You can have multiple Spaces to group related windows and then swipe left & right between them using 3 fingers on your trackpad or magic mouse.

The popular web framework can be used to solve the problem of how to put text on a screen, but it’s almost like someone fed a machine the JavaScript specification and it iterated on a random sequence of code that parses until it hit on a result that creates an acceptable web page.

React’s syntax is bizarre, heavily uses obscure, little used language features that nobody knows about, and in fact only exist because the JavaScript spec is so loose.

There also appears to be no deliberate design or regard for conventions, readability, or structure. Even it’s English terminology looks like something generated by a machine that was fed a dictionary.

componentDidUpdate ???

With a little further reflection, I don’t think the AI accusation is that far off.

Really smart developers just out of college who are tasked with bizarre misguided questions like

How can we write PHP — in JavaScript?

Then, with no real world experience, and being hyperfocused on generating code come up with a solution that satisfies business who care nothing about code.

And then more really intelligent people learn to code by looking at that code and so on… and nobody stops to think about what should be done or how it can be done better. And code is never really maintained anymore — it’s easier to scrap it and just get funding to build a new company.

So a randomized algorithm that generates a solution optimized for a single task is created by a large group of people who think like computers comes up with an answer the same way it would answer the question —

Is this a picture of a cat?

I’ve been looking to level up my Javascript coding skills, and I came across this “mock” coding interview with Dan Abramov by Ben Awad.

I got the first question right (sortof) which asked about the difference between var, let and, const in Javascript. Short answer:

Variables declared with var are hoisted to the top of the function scope.

So if you declare a function with var like this:

function greet() { 
  console.log(x);
  var x = "hello";
  console.log(x);
}

You will not get a compile error. But it will print “undefined” the first time. Because the var declaration is “hoisted” before executing so the function ends up executing something like this:

function greet() { 
  var x;
  console.log(x); // this will print "undefined"
  x = "hello";
  console.log(x); // this will print "hello"
}

But if you declare your variable with let like this:

function greet() { 
  console.log(x);
  let x = "hello";
  console.log(x); 
}

The variable ‘x’ will not be hoisted, and you will get an error:

Uncaught ReferenceError: Cannot access 'x' before initialization

Oh, and const isn’t really a constant. Unless you’re talking primitives like numbers and strings. It only means you cannot reassign the variable — only modify it’s contents. Like this works:

const x = {a:1, b:2};
x.a = 3; // this works, x ==> {a:3, b:2}

const y = [1, 2, 3];
y[0]; = "changed" // this works y ==> ["changed", 2, 3]

I was feeling fairly good about myself, especially when I was able to fairly easily (mostly) solve the CSS question which asked to center a React component vertically and horizontally on the page because I’d recently been playing with display: flex.

body {
  display: flex;
  justify-content: center;
  align-items: center;
  width: 100%;
  height: 100%;
}

Only it didn’t center vertically.

But I got it to work by setting the body height to 100vh (not 100%).

body {
  height: 100vh;
}

Except it was off by a few pixels because of the borders I added to check:

body {
  border: 1px solid red;
}
.App {
  border: 1px solid green;
}

So I compensated:

body {
  width: calc(100vw - 2px);
  height: calc(100vh - 2px );
}

And then I watched how they did it.

Turns out you need to specify: html, body { /* style */ } — but I considered that to be good enough because it’s one of those browser quirks.

html, body {
  width: 100%;
  height: 100% 
}

I was feeling pretty good at that point. And even better when a React contributor essentially said “Don’t use Redux.” Which was what turned me off right at first (ok, after JSX).

I was totally blown out of the water about how to reverse a B-Tree — but it turns out that it was fairly easy using recursion. (I don’t do recursion well).

But the answer is fairly simple once you see it (and trust the recursion):

function invertTree(node) {
  var temp = node.left;
  node.left = node.right;
  node.right = temp;
  invertTree(node.left);
  invertTree(node.right);
}

At least I got the part about only using 1 temp variable.

Next was a real brain teaser … about how to guess which hole a rabbit is in. Out of 100 holes. And it moves every time by 1 hole, either plus or minus 1.

Watch the explanation here:

I was happy to see that Dan Abramov, like myself, considered this be possibly non-deterministic.

The best I could come up with was to either:

1) Guess randomly until I got it right (odds of 1% each try, probably get it in a few hundred tries)

2) Guess the same number (eg. 50) until it lands on that number.

The problem with either of these methods is that it is entirely possible that it never gets it right.

Then Ben Awad gave a hint about how it will always be even or odd.
So here is my solution, unoptimized. I will have to watch to see if there is a better one.

# rabbit.js

function random (n) { return Math.floor(n * Math.random()) } // (generate a random number between 0 and n-1)
function left_or_right() { return random(2) ? -1 : +1 } // (randomly) return -1 or +1 

// rabbit's initial position 
let rabbit = random(100)

function move() {
	rabbit += left_or_right()

	if (rabbit < 0) {
		rabbit == 1
	}
	if (rabbit > 99) {
		rabbit == 98
	}

	console.log(`The rabbit moved to ${rabbit}`)
	return rabbit
}

function look(hole) {
	if (rabbit != hole) {
		console.log(`wrong! (The rabbit was in ${rabbit}`)
		move()
		return false;
	}
	else {
		console.log(`right! (You found the rabbit in ${rabbit}`)
		return true;
	}
}


let hole = 0
let found = false
let guesses = []

while (! found)
{
	guesses.push(hole)
	found = look(hole)

	// finish if we found the rabbit
	if (found) { break }

	// test each hole twice to make sure the rabbit doesn't pass us ( 0, 0, 1, 1, ...)
	guesses.push(hole)
	found = look(hole)

	// check the next hole
	hole += 1
}

console.log(guesses)
console.log(`It took ${guesses.length} guesses to find the rabbit`)