Forem: Felicia Walker

An Extensible React Native App Automation Framework

Felicia Walker — Sun, 20 Jul 2025 03:36:02 +0000

NOTE: I've had the bulk of this in draft forever so it may be a bit dated now. However, the overall approach is still useful and shows how you can combine multiple technologies together for a cohesive yet flexible solution.

I'm going to keep this high level and cover parts of it in other posts. I will also defer detailed framework code stuff to future articles going over what this eventually evolved into.

I was hired at a previous company to create an automation framework to do UI testing on a React native mobile app. Initially simulators would be used but support for real devices in the AWS device farm was be ideal.

Cucumber needed to be integrated so tests would be easier for developers to write and non-technical people to understand. It needed to be written in Typescript and use a tool called Detox that they had been experimenting with.

Components

Here is a brief description of the various components and packages that the framework uses:

Cucumber - Specifically we use cucumber.js which is a runner that links plain language tests, written in the Gherkin syntax, to actual test execution code
Detox - Drives mobile apps by hooking into their underlying code. This allows Detox to know when operations are complete, which makes it more efficient in finding elements. This is what is normally used for testing since it is faster and easier to set up.
Appium - A server that allows you to drive mobile apps externally. It has more functionality than Detox, but is slower and harder to set up. This is needed because the AWS Device Farm does not support Detox. Also, some tests simply cannot be done with Detox’s limitations.
WebdriverIO - A driver that talks to the Appium server and configures it to make using Appium much easier.
AWS Device Farm - What the company wanted to use eventually. It supports Appium tests, and it should be possible to package up the framework along with the tests to run in their Node/Appium environment.

Architecture Overview

The main design focus was to make things easy to use an maintainable while being flexible. This means most of the complexity is encapsulated inside Cucumber steps and in the lower code that supports it. Also, the specifics for executing against Detox or Appium exists only in their own encapsulated classes that can be switched in and out. This was most everything can remain the same, including the actual tests, no matter what OS is used or test runner.

Another aspect is the system for identifying elements inside the app. React supports an attribute called testID. These needed to be added in the app code using a system to ensure they are unique and manageable. In the test framework, these are defined and associated with plain language phrases used in the Cucumber tests. To ensure that this is flexible, a system was made to allow for multiple phrases to be used and support for regular expressions.

The architecture does allow for the possibility of adding web in future, via Appium or adding in a new Selenium driver. A second set of tests would need to be created, however, since the web version has a totally different look and feel than the mobile version.

System Level Architecture

Here is a diagram of the system level with all packages and support files involved:

When a Detox test is run

Yarn is used to run Cucumber.js along with various arguments
Cucumber.js executes tests.setup.js, which creates a shared JS context object capturing command line options and pulls in the cucumber init files
Cucumber.init.ts setups up Detox, configures and runs a server, and hooks into Cucumber for results reporting
Tests are now run with Detox executing actions against an appropriate simulator. It can do this since the installed app has been built with Detox instrumentation.
Results are reported to the console

When an Appium test is run

Yarn is used to run WebdriverIO along with various arguments, including the os type which is required
WebdriverIO executes tests.setup.js, which creates a shared JS context object capturing command line options and pulls in the WebdriverIO config file
Wdio.conf.ts sets the capabilities of the device to run, sets up Cucumber, and configures/starts the Appium server
Appium talks to the device, installs an app for executing actions against the app under test
Tests are now run with WebdriverIO talking to the Appium server, which executes actions on the device
Results are reported to the console

Things to note

The user can manually start an Appium server instead of the framework. This is useful to see what it is doing, and can be faster when running multiple tests.
Local real devices can be used instead of simulators. This is trickier with Detox, and has not been fully investigated.
Running in AWS is left to the future, and will require packaging everything up and uploading it there

When to use Detox or Appium

You will normally want to use Detox locally because:

Detox is faster
Detox is easier to work when developing
Detox seems to be a bit less temperamental when running, probably due to fewer moving parts

However, Appium does have some advantages:

Appium has more capabilities than Detox.
- One big one is Detox can only find elements but not get any info about them. You can’t get the text of an element to verify with Detox, but you can with Appium.
- Appium is much better at dealing with native OS things like action sheets, and gives more control over them
Appium is probably better for running on real devices
Appium can be used to the web (future consideration)
Appium is supported by the AWS Device Farm and probably others since it is a standard

Code Level Architecture

Here is a diagram of the internals of the actual framework:

Features - The tests are written here as plain language using the Gherkin syntax. Each feature file should focus on one particular area.
Step Definitions - These are cucumber files that link the feature keywords to actual code. There is one file per feature file with a common shared one.
Data - Test data is pulled into the steps using factories, but only one for user credentials currently exists.
Pages - Each page file represents one screen of the app. It defines the various elements, their testIDs, and the phrases used to identify them in the feature tests. To ease use, a factory exists that can provide a page object based on a phrase.
Actions - These classes implement a set of standard actions in a driver specific format. A factory exists to provide the proper one based on if Detox or Appium is used.
World Context - This is a global object that captures any command line arguments and other info such as the framework type and os. Cucumber has a native version of this, but it is only accessible by the step definitions.
Loggers - Global loggers to give details about Cucumber, Detox, and Appium actions. The normal level is DEBUG since that provides enough info to troubleshoot failures.

How it works

There are differences in the specifics, but generally Detox and Appium work the same. The tester runs a yarn command (predefined or ad-hoc) which launches packages that pulls configuration files in to set up Detox/Appium and also interpret Cucumber tests. In each test, the plain language of the feature file is linked to actual code via step definitions. The actual code is organized per screen with a standard set of actions available. During setup, the proper concrete implementations of the actions using Detox or Appium commands are linked to these page objects. Both Detox and Appium use their own servers to interact with the simulator or device under test, but via different mechanisms. Their results are interpreted by the Cucumber runner and reported back via the console.

When a command is executed Detox/Appium examines the current screen and tried to locate the element to act on by the testID attribute. This is a special React attribute for the specific purpose of automation. It is a unique identifier defined in the product code for elements used by automation. Since this testID is not very user friendly, a mechanism exists in the page objects that links plain language phrases to the testIDs. The same is also true for identifying which screen (and associated page object) to use in the actual tests.

Conclusion

This may not be the most in depth article, but hopefully it shows how you can build an automation framework that incorporates different technologies in a decoupled way. This allows for flexibility in the vehicles that actually drive an app but also how you can write the tests above.

As mentioned in the note at the beginning, some details will be covered in other posts and the code details in a series on what this eventually evolved into.

References

Mapping Gherkin phrases to page locators - Blog post
System to add automatic testIds to React code - Blog post

GitLab Pipeline Annoyances

Felicia Walker — Mon, 16 Jun 2025 05:10:16 +0000

I used GitLab build pipelines in a previous position where I refactored two files with a complex layout of jobs and functionality. While trying to simplify the flow and reduce the amount of copied code, I ran into a number of annoyances. Some were due to wanting more programming concepts that are not supported but others were basic functionality. I also ran into some items that did not work even though the documentation indicated that they should.

I'd like to gripe about these, but also offer the solutions I came up with in case others also run into these issues.

Disclaimer
I do not have the original files to refer to, but have only written about things I feel I remember well.

Visualization

Lack of connection lines

You think there should be connecting lines between your stages, but frequently there is nothing. The problem is that most of this is figured out at runtime, so nothing can be shown in the visualization. Only links specified by needs or depends are defined ahead of time and can be shown.

Here is a forum post about this.

No visualization when using other branches

If your pipeline has any includes that are on a branch other than main, you do not get any visualization. There is not much to say about this, unfortunately. The visualization in general doesn’t seem to handle includes very well.

Variables

Changing global variables

You cannot directly change global variables from a job once they are defined and set. Instead, you will need to make a step to change the values in a bash script then save as a dotenv artifact. Once saved, the values will be automatically be available to any future steps.

Here is a forum post with an example.

Predefined variables not going to child pipelines

The standard predefined CI/CD variables are not available to child pipelines by default. It seems like they should just be available everywhere, but alas no. If you want to use any of these, you will need to define and pass them in the child pipeline step like any other variable you want to pass.

Shell Scripting

Issues with echos and colons

Putting a colon in any echo statements can cause Gitlab to interpret it as actual syntax, leading to a syntax error. It appears to be an issue with the YAML parsing, not Gitlab itself.

You can try quoting the whole string, but be careful if you are mixing quote styles. There are some other suggestions using templates, in case that does not work.

Multiline echos

An echo with a multi line quoted string may work if this is the only command, but once you use “>” or “|” for a multi step script, this fails. In this case, the additional lines in the echo string are interpreted as another script command.

I never found a good way around this except to split the long string and use multiple echo commands.

When to use braces around a variable

This was never clear to me since many examples usually do not use braces around a variable, both outside of script sections or within them. However, some do put braces around. I always tried to use the braces, but sometimes they seemed to cause problems.

It appears that you cannot use braces unless some text immediately follows the variable. In this case, the braces explicitly group the variable name away from the other text. Here is a post about this with some examples.

Some Good References

Here are some good references I came across trying to figure some of these things out:

Thoughts On Interviewing

Felicia Walker — Sat, 26 Oct 2024 21:40:59 +0000

I have been doing a ton of candidate interviewing over the past year, and have formed some opinions about the process. So what does a software person of many years do when they have opinions? Write a blog article, of course!

I have tried to think of things outside of just having specific experience or knowledge. Even if you nail these it does not mean you will do well on the job. Conversely, if you are weak on either it does not mean you cannot do a job well. What can be communicated to let the interviewer know that you are capable and have strategies for handling different situations (or how can you judge how well a candidate will do)? I am still figuring it out, but I wanted to share a few of the things I have come up with over the years.

General

Learn to judge how detailed your answer should be

Not every answer needs to have large amounts of detail in them. The urge is to show that you really know something, but that may not be what the interviewer is interested in. They may have specific follow up questions, which they may not be able to ask if you give a mini lecture.

I have found balance by including enough information to cover what was asked (and maybe a little extra, if short), but then ask if that was enough or should I provide additional details. Sometimes it helps to mention you will shorten your answer in the interest of time.

It's ok to not know something, but don't make up an answer

No one knows everything and even if you do, you can temporarily forget. StackExchange would not be around if this was not true. If you do not know something, just say so but also say what you would do about that. You can say how you would find out or how it is similar to something you do know.

In any case, do NOT make something up. Your interviewers will most likely know you are trying to cover up not knowing. Doing this on the job leads to bad results and decreases trust in you. And in some cases interviewers are testing you to see what you do when you don't know something. Make a good impression.

Be honest about your level of experience with X

Everyone stretches their experience a bit on their resume, but do not give the impression you have much more experience with something than you do. Especially if it is something in the job description, you will likely be asked questions to ensure you do have the experience.

If you are only familiar with a certain technology, just state that. You can use this as an opportunity to bring up similar items you are more knowledgeable about. You can also segue to an example where you had to learn a new technology/skill quickly and your success. Like the previous point, showing you are enthusiastic and have a plan while being honest can work in your favor.

Technical And Coding Tasks

Talk through your thought process

The most important thing to do when tackling a technical exercise is to let the interviewers know what you are thinking. Silence is awkward but also does not give information to the interviewers. You can ask for a moment to think, but even if you do not have complete thoughts you should describe what you have and where you are going.

As you implement a solution, either explain as you go or produce a small amount of content and recap. Be sure to explain why you are making your choices in addition to what you are actually doing.

It's ok to make a mistake

Almost no one can produce a perfect solution the first time to reasonably complex problems. If you discover you made mistake, do not try to hide it. Admit the mistake and fix it immediately if you can. If the cause it not obvious, do some quick troubleshooting to determine if you can fix it in the remaining time. When in doubt, state what you think is the cause, then ask if you should keep troubleshooting or continue with the task as best you can.

Making a mistake in an interview is difficult. It throws off your flow and can cause you to worry about the consequences. Try to push that aside for the moment and remember an important part of the interview is demonstrating how you handle these situations.

Scope your solution to the time available

It is much better to produce a sub-optimal answer than nothing at all. Do not try to come up with the more efficient or bullet proof solution at first. Mention that this is your initial iteration and it can be improved as needed. You can also give the overview of your idea and that you will figure some of the details out as you go.

You can mention assumptions or leave out portions of the solution not directly relevant to solving the problem (ex: guard clauses to check parameter values). Of course, mention you though of it, but will skip due to time and an revisit if there is time.

Be sure to give a complete implementation

A continuation of the previous topic, you need to be able to deliver a complete solution within the time you are given. Maybe it will not satisfy all the requirements, but better than an incomplete solution that leaves the interviewers guessing how you would turn your ideas into something concrete. Time management is an important skill to demonstrate.

And if you do run out of time and are incomplete, quickly give an overview of what if missing. You probably do not need to say why you could not finish. If appropriate, you may ask if you can send a complete solution via email. However, this is typically not needed unless you were very close to finishing.

Conclusion

I hope these thoughts were helpful. Interviewing is difficult, but try to remember that how you convey your abilities is as important as your knowledge. Fortunately, just vocalizing your thought process, scoping your answers, and asking if more information is needed can help. And remember, no one is perfect. How you handle this is important information for the interviewers.

Good luck out there!

Using Your Own Node Modules With Playwright

Felicia Walker — Tue, 15 Oct 2024 03:27:20 +0000

Most of the time your supporting Playwright code will probably live side by side in directories next to your spec files. However, if you need to share your supporting code with other teams or release it to the public, you may consider using a Node module.

I did just this to share UI, API, and load libraries of supporting Playwright code with other teams. They all had their own repositories and CI/CD pipelines and did not want to clone the test repository and deal with it. Publishing as node packages to a private registry seemed like a good solution. This way other teams could just pull them in like any other module. However, there were complications:

VS code and linters wanted the modules to be in ESM format
Playwright wanted the modules to be in CJS format
You need type files for intellisense

It took a lot of experimenting, borrowing from other open source projects, and swearing in order to get something that fixed all of these. Hopefully I can save you some of that pain with this article.

Much of this article overlaps with my earlier one on setting something similar up for K6

Overview

Here is a slightly simplified version of the Playwright setup I created:

There is sample code you can refer to at my playwright-template-complex-dev respository which covers all sections of this article. It is a simplified version of the diagram below.

There are three custom libraries which reside in their own repositories. The data library are container objects for various app entities. This creates a standard way to pass things around among the various parts. The UI library abstracts UI actions and implements the Playwright ones at a low level. The API library constructs and executes product specific API calls.

These three libraries are published to a private NPM repository. The Playwright code pulls from this, as well as the public repository, for the libraries it needs. It can also import any local files specific to its tests.

I won't cover how to set things up to access a private NPM registry since it depends on a lot of things outside the scope of this article.

Building You Own Node modules

I found you had to compile and bundle your package correctly or you would have issues with your IDE not recognizing types, Playwright not compiling properly, or Playwright blowing up when it tried to run your script. Again, I am working from memory so hopefully I have captured all of the details.

In my example each custom library was originally it was in it's own repository and published as an NPM package to a private registry. However, in the example they are just other directories for simplicity.

The idea is you need both the CSJ and ESM versions in the package. Typescript and modern Javascript want the ESM versions for use with 'import', but Playwright wants the older CJS version for use with 'require' in its compilation process.

How to do it

You will want to have this in your package.json file:

    "type": "commonjs",
    "main": "dist/cjs/index.js",
    "module": "dist/esm/index.mjs",
    "types": "index.d.ts",
    "typesVersions": {
        "*": {
            "somedir/*": [
                "dist/types/somedir/*.d.ts"
            ],
        }
    },
    "exports": {
        ".": {
            "types": "./dist/types/index.d.ts",
            "import": "./dist/esm/index.js",
            "require": "./dist/cjs/index.js"
        },
        "./somedir/*": {
            "types": "./dist/types/somedir/*.d.ts",
            "import": "./dist/esm/somedir/*.js",
            "require": "./dist/cjs/somedir/*.js"
        },
        "./package.json": "./package.json"
    },
    "files": [
        "dist",
        "tsconfig.json"
    ],

The two blocks with "somedir" will need to be repeated for each directory within your package. These additions tell how to find the CJS and ESM versions of your modules files as well as the type files for each.

You also will need an /index.ts file in your source root that exports every file in your modules. For the example above, this could look something like:

export * from './somedir/xyzzy'
export * from './somedir/plugh'
export { default as FrobozzService } from './somedir/frobozz.service'

I ended up borrowing and modifying a build script from the FakerJS project for building and bundling. To build you need to make the CJS version, the ESM version, and put a copy of the CSJ version in the ESM directory.

Once all of this built, you can publish and import into Playwright with no issues. Playwright should also not complain when you run your script and everything is compiled.

Conclusion

Packaging your Playwright code into node modules for use by Playwright and an IDE can be tricky. You will likely need to include ESM and CSJ versions of your code to satisfy both contexts.

Setting up your development environment to accomplish this is not too difficult. It mainly requires the use of a bundler configured to pull in the proper files and deal with them. When using you own node modules, however, you must make sure you build them correctly or issues will arise with your IDE, webpack, or Playwright.

A System For Automatically Adding TestIds To React Code

Felicia Walker — Wed, 11 Oct 2023 00:17:03 +0000

While at OfferUp I had to create automation using Detox and Appium for a React native app. To ensure we could reliably find UI elements, it was decided to use the data-testid HTML attribute.

React has its own specific one for the purpose of identifying elements during automation named testID that gets rendered in HTML data-testid. It does not interfere with any other React functionality. TestIDs should have unique values to avoid fragility and simplify test code.

The Problem And The Solution

Usually testIDs are coded in by developers when adding markup in their React code. However, this is unreliable since people forget to do it, assign too many or too few, can create duplicate values, and use inconsistent naming schemes. This makes it difficult to write tests when you are not sure what to look for or if it exists at all. Adding/fixing testIDs while writing tests is inefficient and painful, and leads to a giant mess.

It would be nice if there was a system in place to automatically assign testIDs in the markup of the React components. Since a React app is typically a hierarchy of custom components, it should be possible to assigned unique values to each component, concatenate these as child components are added, then use the final value as the testID of a React tag.

This solution would also fix another wrinkle. Sometimes Detox/Appium cannot access the data-testid attribute for whatever reason. In this case, the accessibilityLabel attribute can be used instead. In order for this to work, we need to defined it as well in the product code with the same value as the React testID.

Implementation

TestIDs are generally constructed by defining a top level base string at a root component, passing it to children, then having them append to it. At the lowest level, where the actual React tags are used, the value is assigned to the testID and accessibilityLabel attributes.

Example overview

For this article we will lay out things like this for a React native app:

There are our own components which can contain other custom components or React ones. There is a component library (CL) at the low level which define our custom version of UI primitives (ie: buttons, text, etc...). These can use one or more React components.

Assigning our testIDs is mostly done at the CL level, but can also be done at higher levels where View or Touchable are used. Constructing the IDs, however, happens throughout the hierarchy.

Top level components

At the top we have a screen container. The relevant code should look similar to this:

export const MyScreen: FC = () => {
  const topLevelTestID = 'my-screen'}

  // A CL component, so add a descriptor to the id
  <MyCLButton baseTestID={topLevelTestID + '.do-not-press'}>Do not press</MyCLButton> 

  // An intermediate component, so just pass the base and it will append more specific info to the id
  <ChildThing baseTestID={topLevelTestID} />  
}

For ease of use, we define a top level testID base string, topLevelTestID, which will have additional id segments appended to it. This modified string is passed to lower components via their baseTestID attributes.

The name "baseTestID" was used to indicate that the id is not final and to not be confused with React's testID. This attribute is enforced on children via an interface.

If the child component is a CL one, a suffix based on the type, such as ".button" or ".text" will be appended inside the CL class. Therefore, all we need to provide here is a more specific descriptor for the component. The code above will end up assigning my-screen.do-not-press.button to the CL button.

If the component is an intermediate one, we just pass the top level id as a base. This component will then append its own specific identifying info and repeat the process.

Intermediate level components

There are a few things we need for the ChildThing component. The first is an interface to define its properties:

interface ChildThingProps extends BaseTestable {
}

We want it to have the baseTestId attribute and the best way to that is with an interface that can be applied to all of our child components:

interface BaseTestable {
  baseTestId: string
}

Using this interface consistently helps enforce the testIDs and also labels components that use this system.

Now our component itself:

export const ChildThing: FC<ChildThingProps> = ({ baseTestID }) => {

  // Assign a default baseID in case one was not passed in
  const localTestID = (baseTestID ?? 'default') + '.child-thing'

  // A React component so we need to assign the testID and accessibilityLabels directly
  <View testID={localTestID} accessibilityLabel={localTestID}>  
    <ChildThing baseTestID={localTestID} /> 
    <MyContainer testID={localTestID + '.actions'}>
      <MyCLButton baseTestID={localTestID + '.actions.donuts'}>Donuts, please</MyCLButton> 
    </MyContainer>
  </View>   
}

The component first gets the passed in base id and appends a string that describes the component. This is stored in a localTestID variable, which serves as the new base. We also take care to assign a default value in case a baseTestID was not passed in.

There is a React component is here, and we need to assign the testID and accessibilityLabel attributes directly. For most other components, this happens in the CL class which wraps React primitives.

You can also see how there can be components which have a testID attribute instead of a baseTestID one. In this case, the component just uses the passed id as is. The attribute name “testID” is used to connote that it is a final value and will not be appended to. This is mostly used for container components, since we mostly don’t care what type of container it is, so we don’t need to specify any additional information.

Low level components

Finally we have the lowest level components: MyCLButton and MyContainer. MyCLButton is part of our component library, which are leaf nodes in our UI tree. MyContainer is not a leaf node, but is considered a primitive.

MyCLButton will use the baseTestId property since it will append the control type to it:

interface MyCLButtonProps extends BaseTestable {
  buttonText: string,
}

Also like the mid level components it will append information to the testID (here, the control type), but then assign that directly to the testID and accessibilityLabel attributes on the React tags used:

export const MyCLButton: FC<MyCLButtonProps> = ({ buttonText, baseTestID }) => {

  const localTestID = (baseTestID ?? 'cl') + '.button' 

    // React components so we need to assign the testID and accessibilityLabels directly
    <Touchable testID={localTestID} accessibilityLabel={localTestID}>  
      <Text testID={localTestID + '.text'} accessibilityLabel={localTestID + '.text'}>{buttonText}</Text>  
    </Touchable>   
}

MyContainer is very similar, but uses testID instead of baseTestID as its property. This is enforced by having MyContainerProps extend FinalTestable instead of BaseTestable:

interface MyContainerProps extends FinalTestable {}

export const MyContainer: FC<FinalTestable> = ({ children, testID }) => {  

    // A React component so we need to assign the testID and accessibilityLabels directly
    <View testID={testID} accessibilityLabel={testID}>  
      {children}
    </View>    
}

Like the View in the previous section,MyContainer is a React tag and needs a final testID. The child controls will already have their testID information, so they just get passed along.

It is helpful to print out the final testID value in the CL components right before using the React tags. This helps the development of UI tests since you know exactly what is on a screen and what the names are.

A lot of info can be dumped, but you can always send it through a custom logger with options to clean it up.

Conclusion

Here is a diagram of the testID values as they exist in our UI hierarchy:

You can see how a top level base testID is defined and passed down to children, which append their own information and pass that on. Containers do not append their own information since it add noise to its children. Finally, leaf components append their own details about the control type and assign the values directly to the React tag's testID and accessibilityLabel.

This system works pretty well, but can be tricky to use with components like navigation bars and modal dialogs because of their complexity. However, it is not too difficult to implement, creates unique, descriptive names, and reduces the burden on everyone to generate and keep track of testIDs.

K6 Development: Beyond The Basic Setup

Felicia Walker — Tue, 26 Sep 2023 03:40:04 +0000

k6 is a pretty great load testing tool. However, like many test tools it seems easy to use based on the getting started documentation or most articles you find on the web, but get tricky pretty fast if you want to have a more complex development environment.

I am not knocking these articles, because they are valuable and many people are probably fine with the basic setup. However, it does not work well for distributing to multiple teams or long term scalability.

Overview

What makes a more complicated development environment? Well, here are some things I ran into while developing a load test suite based on k6:

Using Typescript
Using Node modules (external and from a custom API library)
Sharing k6 utility files

There were many more things that went into making a robust k6 solution, but I will cover them in future articles. This one will focus on setting up your development environment to be able to handle the above list.

A slightly simplified version of what I was building looks like this:

There is sample code you can refer to at my playwright-template-complex-dev respository which covers all sections of this article. It is a simplified version of the diagram below.

The k6 functionality of calling API endpoints was put into its own library. This was done to make sharing with other teams easier. This library in turn depends on external libraries as well as another custom API library. The API library helps build web request urls and payloads for an API test suite. It made sense to leverage this instead of recoding all of those endpoints in k6.

Both this load library and the API library are published to a private NPM repository. The actual k6 script pulls from this, as well as the public repository, for the libraries it needs. It can also import any local files specific to its tests. The use of the load library greatly reduced the size and duplication of code in the k6 scripts.

I won't cover how to set things up to access a private NPM registry since it depends on a lot of things outside the scope of this article.

As a final note, the load library and scripts each reside in different Git repositories. This was done for NPM package version reasons, but also to keep the checkin histories and processes cleaner. It was also suppose to make it easier for other teams to update the libraries, if needed.

A Bundler: The Key To Everything

A bundler is software that combines Javascript files and dependencies into a single file. Since the k6 engine is Go based and runs scripts in an embedded way, it expects to only pull in single JS files with no dependencies. Therefore, if you do anything with imports or non-vanilla JS, you will need to bundle.

There are many bundlers out there, but for this article we will be using webpack. It is a bit older, but it's what k6 uses in its examples and what I got to work.

Getting Typescript To Work

Basically, you install Typescript, set up a bundler, and use that to compile the Typescript into a single executable file. This sample repository is pretty spot on for doing just this.

The example repository for this article also works, but contains more than just the basic Tyepscript setup.

Using the Typescript only repository above, you really just need to copy the following files into your script location:

tsconfig.json
webpack.config.js
.bablerc

And make sure the following devDependencies are in the package.json file:

"devDependencies": {
    "@babel/core": "7.13.16",
    "@babel/plugin-proposal-class-properties": "7.13.0",
    "@babel/plugin-proposal-object-rest-spread": "7.13.8",
    "@babel/preset-env": "7.13.15",
    "@babel/preset-typescript": "7.13.0",
    "@types/k6": "^0.43.0",
    "@types/webpack": "5.28.0",
    "babel-loader": "8.2.2",
    "babel-plugin-module-resolver": "^5.0.0",
    "clean-webpack-plugin": "4.0.0-alpha.0",
    "copy-webpack-plugin": "^9.0.1",
    "typescript": "^4.7.4",
    "webpack": "5.76.0",
    "webpack-cli": "4.6.0",
    "webpack-glob-entries": "^1.0.1"
  },

Run yarn install to install, and you should be set. Now just build with yarn webpack and a single output JS file will show up in the /dist directory. You can run k6 with this file.

Importing Node Modules

Since k6 is not Node.js compatible, it does not know how to resolve node modules. Therefore, you need to use a bundler to pull them in. There is some documentation on using node modules, but it is fairly basic. The Typescript section above already has most of what is needed for most libraries out there.

From the Typescript only example, you need to make one modification to the webpack.config.js file. It has the /node_modules directory as excluded, but I seem to remember having to undo this. Replace these sections of this file with this code, and you should be good to go:

  resolve: {
    extensions: ['.ts', '.js', '.mjs'],
    modules: ['node_modules'],
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'babel-loader',
      },
    ],
  },

Your own Node modules

Things get tricky when you start importing your own node modules. In my example this is the load-library. Originally it was in it's own repository and published as an NPM package to a private registry, but in the example it is just another directory for simplicity.

I found you had to compile and bundle your package correctly or you would have issues with your IDE not recognizing types, webpack not compiling properly, or k6 blowing up when it tried to run your script. Again, I am working from memory so hopefully I have captured all of the details.

The idea is you need both the CJS and ESM versions in the package. Typescript and modern Javascript want the ESM versions for use with 'import', but Node and k6 want the older CJS version for use with 'require'. In addition, I found you had to copy the CJS version into the ESM destination directory or k6 would be unhappy. There is probably a more elegant solution, but I could not figure it out.

How to do it

You will want to have this in your package.json file:

    "type": "commonjs",
    "main": "dist/cjs/index.js",
    "module": "dist/esm/index.mjs",
    "types": "index.d.ts",
    "typesVersions": {
        "*": {
            "somedir/*": [
                "dist/types/somedir/*.d.ts"
            ],
        }
    },
    "exports": {
        ".": {
            "types": "./dist/types/index.d.ts",
            "import": "./dist/esm/index.js",
            "require": "./dist/cjs/index.js"
        },
        "./somedir/*": {
            "types": "./dist/types/somedir/*.d.ts",
            "import": "./dist/esm/somedir/*.js",
            "require": "./dist/cjs/somedir/*.js"
        },
        "./package.json": "./package.json"
    },
    "files": [
        "dist",
        "tsconfig.json"
    ],

You also will need an /index.ts file in your source root that exports every file in your modules. For the example above, this could look something like:

export * from './somedir/xyzzy'
export * from './somedir/plugh'
export { default as FrobozzService } from './somedir/frobozz.service'

I ended up borrowing and modifying a build script from the FakerJS project instead of using webpack. To build you need to make the CJS version, the ESM version, and put a copy of the CJS version in the ESM directory.

Once all of this built, you can publish and import into k6 with no issues.

Using Non-local k6 JavaScript Libraries

There are a number of k6 provided utility libraries written in Javascript, but are not installed with k6 itself. You will need to download a local copy of the file or use a dynamic import via HTTP.

For a local file, if you don't store the file next to your script you can just use a relative path when you import. However, you may want to make the file available for easier sharing by including in your own library module (especially if you make modifications). This will require the same setup and build process as the Your own Node modules section above. You just need to include the k6 JS files in the index.ts and package.json files.

Conclusion

Getting k6 to work with Typescript, node modules, and using JS files can be tricky. You will likely need to do one or more of these if you build out a k6 based load framework.

Setting up your development environment to use Typescript, Node modules, or multiple files is not too difficult. It mainly requires the use of a bundler configured to pull in the proper files and deal with them. When using you own node modules, however, you must make sure you build them correctly or issues will arise with your IDE, webpack, or k6. You must build similarly if you want share any k6 provided JS utilities or modify them to have any dependencies.

Getting Started In Software Testing

Felicia Walker — Thu, 14 Sep 2023 18:36:23 +0000

There are a number of articles out there about how to get started in software testing, but this is mine. I know several people who are interested in testing and I would like to collect some thoughts and resources in a shared place for them. So, this will be more informally written but hopefully still useful for folks in general.

Links within the article point to something that serves as an intro to that topic, and hopefully a jumping off point for further research.

What Software Testers Do

If asked, most people would say software testers find bugs. This is true, but it is part of a larger mission of assessing the state of the product and reporting the risks to decision makers (borrowed loosely from James Bach). Testers use a product, sometimes in a focused or novel way, to see what works and what does not. They report their findings to others who can prioritize and make decisions about releasing in this state. Sometimes bugs need to be fixed. Sometimes it's ok to risk releasing in a less than perfect condition. Testers are the ones who gather the detailed information to aid in those decisions.

Day to day this involves creating, writing, and executing tests or other test related activities. Documentation and analyzing results are also frequent tasks. As a tester progresses in their skills, they may start to write automation code to help speed up their testing or execute tedious portions.

Important Skills

Even at entry level there are a number of skills that are good to have, or at least be familiar with. Ideally these would be taught to you as a new employee, but that's not how things generally work these days. Fortunately there is the lovely internet to help fill the gap.

While technical skills are important, to be successful at testing long term you need certain soft skills as well. These are important even in the most robotic form of testing where you just execute test cases.

Technical

Familiarity with the SDLC

The SDLC is the Software Development Life Cycle. Basically, it is the process a company uses for turning business requirements into features, getting them into a product, and shipping that product.

There are many types of processes, but the two you should be familiar with are waterfall and agile. Waterfall is the more classic, linear version and agile is more modern. It was created to address inefficiencies with waterfall.

General test concepts

There are a few general test concepts that are good to know. I would be surprised if they did not come up in an interview.

The biggest general concept is the test pyramid. The idea is that most tests should be targeted, quick unit tests, then fewer integration tests to ensure components work together, and a small amount of end to end tests, which are slow and can be flaky. While not perfect, the pyramid is a bit of a standard. Looking into it is also a good jumping off point for test types and techniques.

Another general concept is defect tracking. Every company has a different way to track the discovered defects, but the flow is generally the same. Knowing how to document a defect, how to report it, and what happens to it during and post fix are important.

I should mention exploratory testing somewhere. This is a test concept based on exploration and the skill of the tester instead of a checklist of test cases. It gaining more traction and is worth reading about. Personally, I think it is a much better way to test than more traditional paradigms.

Basic test techniques and heuristics

There are a huge number of test techniques that can be applied. You do not need to know all of them, but know these at a minimum:

Black/white/grey box
Unit/integration
Load and performance
Security
Internationalization/localization
Accessibility
Usability

There are also heuristics, or guidelines, of activities you can do within each of the above areas. These include things like decision tables, flow charts, domain analysis, and many others.

Here are some comprehensive lists with more details:

Heuristic cheat sheet - Bounds to check, pearls or wisdom, and other suggestions
Heuristic Test Strategy Model - From James Bach, this doc has several large lists of heuristics to keep in mind

Coding

Knowing how to program is not required to test software, but it does help greatly. It will help you view the product source code so you can troubleshoot better and understand the unit tests. Coding allows you to create utilities to help with your testing. Even if this is not full test automation, small ad-hoc programs are useful for verification and generation of large data sets. You can also automate tedious tasks.

I would recommend learning Javascript or Python as a first language. Both are very common, easier to pick up, and do not require a compiler (although there are plenty of online development environments now). If you choose Python, use the 3.x version, not the legacy 2.x version.

Here are two good sites for learning how to code:

Codeacademy.com - Free beginner coding lessons
Exercism.com - Another free site for learning programming languages. It offers quite a few, 67 total, including more advanced languages.

Soft

Lateral thinking

I've come to realize that lateral thinking is incredibly important for software testing. The ability to not only have a Plan B, but a C, D, E, and beyond is necessary since things frequently do not go as planned. This not just for creating test cases, but setting up the conditions for testing and how to work around issues and troubleshoot them.

Besides having a lot of computer or testing experience, it is difficult to develop this skill. Personally I have had success by working on puzzle hunts and playing heavier board games. You get exposed to a variety of puzzles and mechanics that require you to think outsie of the box. These activities also help you build tenacity.

Tenacity/Grit

The ability to stick with a problem and see it through to the end is important. This usually arises when trying to narrow down a defect's behavior or executing difficult test cases. It may not be easy to figure out what to do next, unravel complex behavior, or avoid getting frustrated. Of course, you should also know when something is too difficult and how to ask for help.

The standard advice is to try something you are not good and, practice a lot, and don't give up when it is hard. Good news is that this will happen as you pursue your testing career. Bad news is that it is very difficult in any context. You could also try some of the suggestions above under Lateral Thinking. Puzzles and board games can be difficult, but also more bite sized activities.

Documentation/organization

Being able to record ideas, activities, and findings are very key for a software tester. You will need to document tests you create and in a format that is easy to follow. You will need to document your findings and write up defect reports. Cleanly written reports make the bug fixing process more efficient and cuts down on your amount of work in the long run, developers and program managers will spend less time getting clarifications with you.

Education / Certifications

Most testing positions, even entry level, will want you to have a Bachelor's degree in computer science or a similar field. And now my very personal opinion:

When I started none of the testers had this. I have two electrical engineering degrees, but others had degrees in history, applied match, and analytical chemistry. We all did fine. It's not like a CS degree will teach you anything about testing, so the requirement seems like gatekeeping. Maybe having the college experience is valuable, but I know people who are amazing engineers who don't have a degree at all.

I guess what I want to say is don't feel like you have to have a four year degree in CS before applying. With the internet of today you can learn much more applicable skills online and create a portfolio to demonstrate them. It may be harder to break through that initial round of interviews, but I would also hope companies at least consider everything else on a resume before rejection. Probably a bit naive of me, but I have to try and think positive when I can.

Online courses

There are many places that offer courses in software testing. Many cost, but are probably worth the money (especially compared to a university). I know there are also lots of YouTube and probably TikTok channels that offer content as well. The following have software testing specific courses, and are generally regarded as top learning sites:

Udemy - A popular online learning site. Most courses are paid, but frequently discounted. Here is a free intro course.
Coursera - I have not used it, but it is frequently recommended and has free courses
Pluralsight - You need to log in to view the catalog. There is a 10 day trial, but it can be a bit pricey after that. There is not much testing content, but a ton of software stuff in general. I've used them for years and found it worth the money.

About certifications

Many articles talk about ISTQB certifications and how those are alternatives to school or a supplement to it. Many organizations also list them as job requirements. However, they are expensive. Cue my personal opinion again:

From what I've seen these certifications teach an older and more limited idea of what software testing is. Worse, it passes their content off as the industry standard and if you don't follow it, you are lacking. I also have issue with certification programs in general, since they frequently seem like cash grabs and don't offer much in terms of learning skills.

That said, it is worth looking at ISTQB content, but I would not pay their expensive costs. Also, the content provides a decent basis of testing skills and ideas, but they are not the end all be all of testing! Please don't spend all your time focusing on this. It may seem like a smart move for getting started, but your time and money can be better spent.

Getting Experience

And now the hardest part of getting started, obtaining experience. Ideally you would get this in an entry level position, but for some reason companies want testing experience even for entry level jobs. This is doubly baffling to me since its much easier and common to have programming experience than testing. But there are ways to gain experience outside having an internship as a student.

Crowd sourced freelancing

There are a number of companies that use freelancers to perform test work for clients. The clients supply the tests to run and what devices to run them on, the company distributes that to their freelancers, who run the tests and report back, and all the aggregated results get returned to the client. These freelancers are anyone who signs up and completes some basic training. I do not have experience with this, but it seems like an excellent way to get experience and get paid at the same time. I'm sure the amount is not much, but still.

Here are a few resources to check out:

Top 10 list of crowdsourced test companies
uTest - Seems like a popular option
Testlio - Used by a company I worked a contract for. They seemed happy with them.

Pair with mentor

If you can, find a senior software tester who can be a mentor. Besides passing on skills, they can offer suggestions on how things are done in the real world and ideas on what to study. You could also work with a mentor on pair testing or other activities such as reading discussions.

Finding a mentor can be difficult. If you know people in tech, ask them if they know of anyone. You can also check out local meetups and groups. Finally, some of the larger testing sites on the internet have mentoring resources. Here is one from The Test Tribe.

Test random things and write posts or keep notebook

You can always test things around you and record the results. It doesn't just have to be just software. You can look at any piece of technology, or the system it is a part of, and start creating test cases, strategies, and configurations. You could also do a bit of exploratory testing and note down what you did, much like a scientist recording research.

Michael Bolton does this with a notebook, but you may want to use something that can be shared online. A tool like Miro or an online note taking app would work. Of course, you could always just take pictures of your notebook pages and share as an image gallery for portfolio purposes.

Open source contributions

Contributing to an open source project is something that you can link to and demonstrates you have worked in an actual software development flow. Take a look at the list of issues for projects you already use. Some may need further testing or be narrowed down. You could do that and add your findings. You could also test on your own and submit any defects you find.

The testing you do does not need to be limited to functional cases. You could run accessibility tools, security tools, or review the unit tests. Heck, maybe they don't have unit tests at all, so you could ask to establish some. Doing all this will also give you a feel for what it is like to work with a developer to improve the codebase.

Conclusion

I know if has been forever since I started my software testing career and that the bar is higher since then. However, there are tons of resources out there to help you. I hope what I've presented here is useful. I thought about what I look for when I interview junior testers and what is really important about being a good tester. Some of it is a little non-standard, but it's important to recognize when existing things need to evolve.

If you have any questions, please post in the comments below or send me an email.

A System For Dynamically Handling Element Names In Cucumber

Felicia Walker — Fri, 08 Sep 2023 22:46:24 +0000

This is a followup post to my cucumber style guide. I felt it was getting too long, so I split this topic off into its own post.

The Problem

Sooner or later you will have steps in your feature file that are the same in many places except for a word or phrase. Usually this is something like a user name, screen element, action, or index. For example, if you had the following scenarios (or more than this of the same form):

  Scenario: One
    Given The user is on the home screen
    Then The user sees the search bar element
      And sees the categories bar element
      ...

  Scenario: Two
    Given The user is on the settings screen
    Then The user sees the username element
      And sees the password element
      ...

Each line would need its own step definition, but what those steps do would basically be the same. In this case the Given statements would verify we are on the proper screen and the others verify some UI element is present.

It would be better if there was a way to eliminate duplicate code in the step definitions by collapsing these similar steps. Fortunately, this is possible and there is a way to expand upon that to be even more flexible.

The Simple Solution

The simple way to collapse the step code is to make use of step arguments. Step arguments allow dynamic values to be extracted during the step matching process. See here for details about how to do this via regular or Cucumber expressions.

Refactoring the above example involves making the screen name a parameter for the "is on" steps and the element name a parameter for the "sees the" steps. While you can change the step matchers only, it is a good idea to add some delimiters around the dynamic values. This marks them clearly in the feature file as well as making it easier to write the matchers.

The feature file now looks like this:

  Scenario: One
    Given The user is on the "home" screen
    Then The user sees the "search bar" element
      And sees the "categories dropdown" element
      ...

  Scenario: Two
    Given The user is on the "settings" screen
    Then The user sees the "username" element
      And sees the "password" element
      ...

The step code changes to this (note, it is written in Typescript and uses regular expressions for matching):

Then(/^The user is on the "(.*)" screen$/, async (screen: string) => {
  switch (screen.toLowerCase()) {
    case 'home':
      await homeScreen.isScreenPresent()
      break
    case 'settings':
      await settingsScreen.isScreenPresent()
      break
    default:
      throw new Error('Invalid screen name')
  }
})

Then(/^The user sees the "(.*)" element$/, async (element: string) => {
  switch (element.toLowerCase()) {
    case 'search bar':
    case 'categories dropdown':
      await homeScreen.isElementVisible(element)
      break
    case 'username':
    case 'password':
      await settingsScreen.isElementVisible(element)
      break
    default:
      throw new Error('Invalid element name')
  }
})

You can see how we capture everything within the quotes, which gets passed as the single value to the associated method. A switch statement executes code specific to this value. As seen in the second step, case statements can be grouped together if the call to supporting code is the same.

While this is an improvement over single steps for everything, it is very likely the code called in the case statements will still be very similar to each other. If we are clever, we may be able to further collapse the step code.

There is also the problem with name collisions in the switch statements. However, these can be fixed with rules around how we name values passed to the step definitions. In our example, if two screens had an email field, we would need to name them "screen 1 email" and "screen 2 email". The screen name must be passed to the step in order to have two unique case statements.

A Better Solution

The cleverness mentioned above involves the use of factories and interfaces. A factory is used to instantiate the object to act upon instead of using shared global instances. Since these objects will all be similar, they can implement an interface of common actions. Together this allows the lengthy switch statements to be replaced with a single line:

Then(/^The user is on the "(.*)" screen$/, async (screen: string) => {
    await ScreenFactory.getScreen(screen).isScreenPresent()
})

Then(/^The user sees the "(.*) > (.*)" element$/, async (screen: string, element: string) => {
    await ScreenFactory.getScreen(screen).isItemVisible(element)
})

For our example the factory returns a screen instance. We need to pass the name of the screen to get, which is extracted directly from the cucumber text.

Note, to get the screen name when specifying a element we introduced the naming rule of "Screen > Element". The use of ">" makes the extraction regular expression much easier to code.

It also helps make the feature file text better by clearly dividing sections of the name. This is especially beneficial with deeper elements (Ex: Settings > Integrations > Email > Server).

Once we have our object to act on, we can call the actual action with the appropriate parameters. Since the factory generated objects all implement the same interface, we guarantee that these actions are valid all of the time. If we do happen to have any exceptions, we can still have some logic to account for those as needed.

Conclusion

No matter what you are automating using Cucumber, patterns in the text will form. By imposing simple rules about naming the dynamic shared portions, you can simplify the underlying step definition code. Also, by using the factory pattern along with interfaces the step definition code become cleaner and even more compact.

Obviously I am highly biased, but I like this pattern since it results in simple, readable step definition code as well as very clear feature file text. I hope you will give it a try.

My Cucumber Style Guide

Felicia Walker — Sat, 26 Aug 2023 01:43:21 +0000

While at Offerup.com I had to use Cucumber to run Gherkin style tests. I had not used this style of test writing before. While it seems easy and straight forward at first, I quickly realized that its flexibility would allow the wording and structure of tests to quickly diverge and become unmanageable.

Here is my approach to writing decent tests, Gherkin best practices, and how to name elements. These guidelines are designed to make the tests as understandable, concise, and flexible while reducing duplicated code. A lot of ideas were taken from this Automation Panda post, which is good reading.

General

Describing behavior in a concise manner is the most important thing
You should strive to use short phrases to accurately convey what each line is doing
What you write should describe what you are doing, not how or why
Feature titles should follow the Scenario rules below
Do not use the Rules keyword. More than one is not supported by cucumber.js, which makes it very awkward
Try to not use the Background keyword. Since it is common setup, it can render the Given sections of tests irrelevant. Leaving out the Given then makes the flow odd.
- You could use Background then make a step definition for “Given The Background task passed” and have it do nothing. This would just serve to create decent Gherkin in the spec file.

Example

  Scenario: Create a new account using valid information
    Given The user starts on the create account screen
    When The user enters valid account information
      And presses the "Create Account > Create Account" button
    Then The user arrives at the "Secure Your Account" screen

The wording is concise and describes what is being done so anyone can easily see what this test does. It is also worded in a way that allows for flexibility with dynamic items (phrases in quotes).

Embedded Test Data

Don't use scenario outlines or data tables to execute extra cases you don’t need just because you can
- This increases the execution time and increases the change of a random failure
- Most of the time one element of a behavioral set is fine to verify the behavior of all. For example, you don’t need to open up every search category if they all look the same, but you may want to do one of one type and one of another if they can result in different results.

Example

  Scenario: The first message page contains the proper elements
    Given The user is logged in
    When The user taps the "Item > Inquire" button
    Then The user sees these elements on the "Send Message" page
      | Send A Message Heading |
      | User Profile           |
      | Item Details           |
      | New Message Input      |

A data table is appropriate here since we want to verify a number of elements are present. One may be sufficient if we just wanted to know if we were on that page, but the Scenario clearly says we want to verify all proper elements.

  Scenario Outline: Send a first message with each suggested message
    Given The user is logged in
    When The user taps the "Send A Message > <suggested response>" button
    Then The first sent message is "<suggested response>"

    Examples:
      | index | suggested response             |
      | 0     | Hi, is this still available?   |
      | 1     | Hi, I want to buy this         |
      | 2     | Hi, can you meet?              |
      | 3     | Will you ship via Frobozz?     |

Like the previous example this makes sense since we want to test each option presented to the user and each results in a different behavior.

Scenario Text

Scenario titles should be one line, any additional info can go in the description
- Watch out for usage of "and" and "or" which can indicate the need to split into multiple scenarios
- "Because", "since", and "so" portions can be left out since they describe why you are doing this, not what
- No "verify" or "should" since that is about assertions, not describing behavior. This belongs in the steps.

Examples

  Scenario Outline: Send a first message with each suggested message

Not bad, but the "suggested message" part could probably be cut or moved to the Description section.

  Scenario: Selecting the email login method takes you to that landing page

The "takes you to that landing page" part has an implicit "should" in front of it and should probably be removed. This phrase describes a result, and that should be covered by a subsequent Then statement.

Scenario Content

Scenarios should be 10 lines or less
Try to have only one Given/When/Then flow per scenario. This is the idea of one scenario equals one behavior.
Lengthy sections can be encapsulated into a single step definition. This could also enable reuse of behavior since it is done outside of the spec file.
It may be possible to skip long setup sections by directly navigating to the start of the actual test. This is most appropriate for UI tests.

Examples

        Then The user sees the "Account > Public Profile Name" element
            And sees the "Account > Public Profile Ratings" element
            And sees the "Account > Public Profile Bought Count" element
            etc...

All of these conditions could be collapsed into a single step definition and replaced with something like:

     Then The Account page contains all expected elements

Sometimes you may want to break the single Given/When/Then block in the scenario: If a test depends on the state of a previous test and there is not an easier way to set up those conditions atomically. You could make a step definition and use it twice in two tests. However, this could greatly increase run time since you are executing a long section of behavior twice.

Instead, you could do something like this:

Scenario: Scrollable items can be scrolled
    Given The user is on the "Home" screen
    When The user swipes "left" on the "Home > Category Bar" section
    Then The user does not see the "Home > All Categories" button

    Given The previous block passed
    When The user scrolls the "Home > Items Grid" section "down"
    Then The user does not see the "Home > Main Search Bar" element

The step “Given The previous block passed” actually does nothing in it’s step definition code. It is just here to provide proper Gherkin by saying what is going on. This allows you to build off previous functionality, but still break things up into individual Given/When/Then blocks that are atomic.

The drawback is this is really multiple tests per scenario, and will be reported as such in the results. But the time savings and code reuse is worth it.

Steps

Each step should be less than 120 characters
Reading each line by itself should tell you exactly what it is doing. Use the form: subject, action, predicate
Don't spell out content that is implied, such as pressing Submit after doing something
Try to not depend on exact data if it doesn't matter (ex: if you just care the list has content, look for a first item, not "item equals X" in your data)
Hide data in step definitions instead of polluting the feature with it, unless it is critical to having the step text make sense
Like scenario titles, if you have “and” or “or” in the text, split it into multiple steps
If you have more than one or two Ands or Buts, you probably need to encapsulate them into a new keyword with a more descriptive name

Example

    Given The user is logged in as "Test Seller"
      And has at least one message
    When The user opens message number 1

Here the steps are short and declarative. There is some data included, but it is needed to specify an exact object acted upon.

The And clause is a separate behavior and split off like this. It also is made more generic since we just care that we have a message, not what it is or any other details.