DEV Community: Dylan Lacey

You're It! Ersatz tagging in Cypress, using Saucectl.

Dylan Lacey — Wed, 01 Jun 2022 08:01:11 +0000

How good is tagging?

Rhetorical question; Tagging is great; my favourite organisation system, in fact. Test systems with tagging allow you the flexibility to organize your tests according to what code they're testing, while running tests according to what kind of test you're after.

Tagging & Cypress

Unfortunately, Cypress lacks native support for tagging, and this makes me very sad face emoji.

Fortunately, with saucectl, we can retrofit tagging functionality onto our Cypress tests, whether you're running locally in Docker mode, or remotely against Sauce Labs' cloud.

Wait, what's saucectl?

Let's go to the README!

The saucectl command line interface orchestrates the tests in your framework, providing rich parallelization, test history filtering, and analytics in Sauce Labs.

Basically, saucectl is an amplifier for your tests. It drags your Cypress, Playwright, TestCafe or Puppeteer kicking and screaming onto the Sauce Labs cloud, giving you delicious Sauce features (like analytics) along with all the goodies your framework has to offer. Saucectl can also run your tests with Docker, giving you a quick and reliable test environment. It's a great solution for using Cypress with CI.

Our Approach

In config.yml (the config file for saucectl), you can specify individual suites see here which let you provide individual config options to Cypress.

By passing the testFiles option to Cypress, you can control which individual files it runs. We're going to combine these two, to give us individually named test suites, each of which runs tests with a specific set of tags.

Can't you do that with Cypress alone?

Yes, technically, but I prefer this approach for... let's call them ideological reasons.

While you could have individual config files, and call cypress run --config-file somesuite.json for each one, it's messy. If you make changes to one suite file, you have to make it across all of them, which is easy to forget.

With this solution, all your Cypress config stays as is, and only the tests being executed are changed. Even better, control of which tests run is maintained in the infrastructure configuration, and infrastructure is likely to have the most significant impact over what 'flavours' of test you want to run.

How we're implementing tagging

This solution makes use of globbing, a way of selecting a group of files. It's pretty common; Common enough to have a Wikipedia page, and you've likely seen at least one glob before.

We're going to alter our tests so each test suite is configured to run a set of globs corresponding to our tagged tests.

Example

Suite Files

Say this is our test suite. Each file contains tests that should only run on a specific browser (or combination of browsers). We've named them so each filename includes the relevant tags, separated by underscores, like _chromeOnly or _ieOnly. These could just as easily be _ui or _FrenchLanguage or anything you want to tag by.

specs/
  ui/
    login_chromeOnly_spec.js
    login_firefoxOnly_spec.js
  accounting/
    jsMathBugFix_ieOnly_spec.js
    chromiumCantCount_edgeOnly_chromeOnly_spec.js

Config.yml

Here's the suites component of our config.yml. Each suite has a unique glob for testFiles which finds all tests in your specs folder which include the respective tag/s.

  suites:
    - name: "Where There's Smoke There's"
      browser: "firefox"
      platformName: "Windows 10"
      config:
        testFiles: ["specs/**/*firefoxOnly*_spec.js"]

    - name: "Cream on"
      browser: "chrome"
      platformName: "Windows 10"
      config:
        testFiles: ["specs/**/*chromeOnly*_spec.js"]

    - name: "Livin' on the"
      browser: "edge"
      platformName: "Windows 10"
      config:
        testFiles: ["specs/**/*edgeOnly*_spec.js", "specs/**/*ieOnly*_spec.js"]

How it works

Each glob starts with specs/**/*. This glob means "start in the specs folder (specs/), then look in any subfolder(**), for any characters at all(*) followed by an underscore(``)".

Let's look at how the first glob continues. After specs/**/* we have firefoxOnly*_spec.js. This means "find anything containing the phrase firefoxOnly, followed by zero or more of any character(*), followed by `_spec.js". For our tests, that only matches specs/ui/login_firefoxOnly_spec.js`.

The second glob is specs/**/*chromeOnly*_spec.js, so it matches every file in every subfolder of specs which contains chromeOnly, followed by zero or more of any character, followed by _spec.js. In our case, that's specs/ui/login_chromeOnly_spec.js AND specs/accounting/chromiumCantCount_edgeOnly_chromeOnly_spec.js

Did you notice?

The testFiles parameter doesn't take a glob directly; it takes an array of globs. That lets us pass in multiple entries, which is how suite three works. We're able to pass in two entries, one for any test tagged edgeOnly and one for any tagged ieOnly. It will match any file in either of those blobs; in this case specs/accounting/jsMathBugFix_ieOnly_spec.js and chromiumCantCount_edgeOnly_chromeOnly_spec.js.

Additionally, test files can have multiple tags. This is really useful when you want to run some tests in multiple scenarios; Say you have a limited set of functional tests that are also used to ensure deploys go well; You could tag them _functional_postDeploy_spec.js and they'd run when using either the _functional tag or the _postDeploy one.

And that's it!

A small change to how you name and select tests, and you're left with a more flexible testing system. And of course, you can still run a default suite with no tags, and make sure you're running everything.

Happy Testing!

Credits

Photo by Angèle Kamp
on Unsplash

Better Debugging Output: The Console.Assert Way!

Dylan Lacey — Wed, 13 Apr 2022 13:24:23 +0000

Debuggers? In MY Console?

Using the console to debug applications seems to make people big mad.

The thing I find objectionable about the "Don't use Console!" story can be summed up by this quote:

many developers regularly use the console object’s log method in a way that I think is incorrect.

See, the thing is, despite having (and perhaps one day sharing) rebuttals for many of the admittedly well made points, the truth is that I simply don't care if you think I'm wrong and ultimately you can't stop me.

I like using console debugging despite knowing of "Better" solutions. This series is going to explore features of the JS Console I don't see as often as the venerable console.log(), in the hopes that you'll like it too. This time, we're making our logging less verbose, with console.assert().

Console.assert

Console.assert?

Yes!

You call console.assert() with a boolean condition and a message; The message is only output if the condition evaluates to false.

console.assert(someMsg.includes("All is Well"), "There has been An Incident.")

// someMsg = "Calamity! Perfidy! Tragedy!"
// Output: 
Assertion failed: There has been An Incident.

Why is this better?

Logging can give us different kinds of information. Some log data is structural and lets us know what code is executing.

Some log data is operational and lets us know what data is being executed on.

Typically, I want all structural log data when I'm debugging, so I can fully trace my application flow. Contrariwise, I only want operational data that relates to the error I'm tracking down. If an error-like condition hasn't occurred, operational log data often doesn't tell me anything.

The Beauty of Asserting False

I usually only want output if the expected behaviour doesn't happen, so semantically, this makes sense. I tell the JS engine what I want, and it only alerts me if it doesn't happen. Mentally, I only have to think about what "correct" looks like, not what might be "incorrect".

Make the output better

Auto-append object values

Another console.assert option is to pass a condition and an array of objects. If the condition is false, the objects are stringified, appended together and output. This can save you writing a custom error message, which is 🧑🏼‍🍳💋.

let good_investments = ["Mines", "Urchins", "New Fangled Electricity"]
let bad_investments = ["Radium Health Tonics"]

console.assert(bad_investments.length == 0, bad_investments);

// Output:
Assertion failed: Radium Health Tonics

Output Formatting

What if we want something more then just a set of object values? We could pre-format a message string, or.... We could use string substitutions to do it inline!

let good_investments = ["Mines", "Urchins", "New Fangled Electricity"]
let bad_investment = "Radium Health Tonics, Inc."

let losses = {
    pounds: 150,
    reputation: 47,
    body_parts: ["Teeth", "Jaw"]
}

console.assert(
    bad_investment.length == 0,
    "%s has cost you %d Pounds and reduced your reputation by %f%",
    bad_investment,
    losses.pounds,
    losses.reputation
)

//Output:
Assertion failed: Radium Health Tonics, Inc. has cost you 150 Pounds and reduced your reputation by 47%

If you're confused about the use of string placeholders (%s and %f), check out my rapid guide to the Console method string substitutions.

Object String Substitution (My favourite bit)

In fact, that same article shows off Object substitution, which is extremely useful here. Instead of:

Assertion failed: [object Object]

Object substitution lets console.append return a nicely formatted message to the CLI... and an expandable, clickable Object in the browser console! Click it, and you'll go directly to the inspector to dig around and see what's gone wrong.

console.assert(
    false, 
    "Your %O exceed %d pounds. See %o.", 
    losses,
    losses.pounds,
    losses.history
)

//Output:
Assertion failed: Your >Losses exceed 150 pounds. See >History.

Wrap-up

So that's the power of console.assert! Rich, compact debugging messages that show up only when needed, giving you ample ability to present and explore the relevant information.

If you liked this, please hit the Dopamine Switches (🦄❤️) on the left, and subscribe to my writing for the next entry in the JS Console Debugging series!

Recognition

Header image is by @Sigmund, used under the Unsplash License.

Cool Console stuff: Easy object inspection

Dylan Lacey — Wed, 06 Apr 2022 02:37:06 +0000

So here's a weird thing.

The console methods have their own C-like String Substitution methods.

Wait, String Substitution?

Literally, substituting part of a string for something else. In Programming Land, that usually means building strings via interpolation or formatting strings:

guest = {name: "Fortesque-Delcourt", calling_gift: "a rather nice sherry"}
console.log( `Sir, Mr ${guest.name} has called. He's bought ${guest.calling_gift}` );

// Output:
"Sir, Mr Fortesque-Delcourt has called.  He's bought a rather nice sherry."

OK so you can add strings, so what?

You can build strings with Template Literals, or string concatenation, but the "C-Like" formatting referred to in the docs means you can pass a templated string and the replacements as arguments to log method:

console.log(
    "Sir, Mr %s has called. He's bought %s", 
    guest.name, 
    guest.calling_gift
);

// Output:
"Sir, Mr Fortesque-Delcourt has called.  He's bought a rather nice sherry."

You're not restricted to substituting strings literally. Instead, the templating engine tries to convert the passed object into the data type specified by the placeholder.

Let's say we have an object representing the investment losses of a Victorian investor:

let losses = {
    pounds: 150,
    reputation: 45.7,
    body_parts: "Teeth"
        faith: ["The Markets", "New-Fangled Steam"]
}

Here's what you get when you pass various types to the different placeholders:

Template String	losses.body_parts	losses.pounds	losses.reputation
"Lost: %s"	"Lost: Teeth"	"Lost: 150"	"Lost: 45.7"
"Lost: %i"	"Lost: NaN"	"Lost: 150"	"Lost: 45"
"Lost: %f"	"Lost: NaN"	"Lost: 150"	"Lost: 45.7"

Is this useful?

No, not particularly. It does let you see at a glance if you pass a String into an Integer or Float placeholder but that's hardly going to save the world.

What is useful is the Object placeholders, %o and %O.

The Object Placeholders

If you call console.log while combining an Object with a String (eg console.log("Your Object, Sir" + obj), you're likely to get back the stunningly unhelpful default toString output:

[object Object]

This is both unhelpful and gross... However! If you use one of the Object placeholders, you'll get something that represents an enumeration of the properties and their values. What kind of something depends on the operator, and what kind of console you're using.

Node.js CLI

From the CLI, calling console.log with the uppercase %O operator will generate an inline enumeration of properties.

Using the lowercase %o will enumerate the object's properties over multiple lines.

Inline (with %O)

console.log("%O", losses)

//Output:
{ pounds: 150, reputation: 45.7, body_parts: 'Teeth', Faith: ['The Markets', 'New-Fangled Steam'] }

Multi-Line (with %o)

console.log("%o", losses)

//Output:
{
  pounds: 150,
  reputation: 45.7,
  body_parts: 'Teeth',
  Faith: ['The Markets', 'New Fangled Steam', [length]: 2]
}

Browser Console

In the Chrome console, things act sort of backwards. Here, the lowercase "%o" operator will return an =inline= enumeration:

Inline (with %o)

console.log("%o", losses)

// Output:
> { pounds: 150, reputation: 45.7, body_parts: 'Teeth', Faith: ['The Markets', 'New-Fangled Steam'] }

Object Linking (with %O)

The cool part, however, is with %O. Using the uppercase format, the output string will contain only the object's name... Which is clickable, taking you to the inspector to let you poke around!

Let's say our losses object is an instance of the Losses class, and it also contains some sort of history object. We can create a rich, readable debugging message which gives us easy access to object internals, but doesn't clutter up the console:

console.log(
    "Your %O exceed %d pounds. See %O.", 
    losses,
    losses.pounds,
    losses.history
)

//Output:
Your >Losses exceed 150 pounds. See >History.

Wrap-up

So that's the power of Console String Substitution! Easy formatting for terse but richly informative console messages.

If you liked this, please hit the Dopamine Switches (🦄❤️) on the left, and subscribe to my writing for the next entry in the JS Console Debugging series!

Recognition

Header image is by @Sigmund, used under the Unsplash License.