• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Practices & Products
  • Learning & Growth
  • Culture & Careers
  • Blog
  • Contact Us

DevOps

May 08 2023

InRhythm Presents The Propel Spring Quarterly Summit

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

New York, NY – InRhythm recently concluded its very first Propel Spring Quarterly Summit; a premiere event consisting of six individual coding workshops aimed to support the learning and growth of engineering teams around the world. 

Over the last three weeks, our consulting practices have led a series of interactive experiences that delved into the latest technology trends and tools, designed to propel professionals forward into their careers. 

The workshops are free to access as a unique part of InRhythm’s mission to build a forward-thinking thought leadership annex:

  • InRhythm Propel Spring Quarterly Summit / SDET Workshop / March 17th 2023
  • InRhythm Propel Spring Quarterly Summit / Web Workshop / March 24th 2023
  • InRhythm Propel Spring Quarterly Summit / DevOps Workshop / March 29th 2023
  • InRhythm Propel Spring Quarterly Summit / Android Workshop / April 11th 2023
  • InRhythm Propel Spring Quarterly Summit / Cloud Native Workshop / April 21st 2023
Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

SDET Workshop (03/17/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

This workshop worked as an introduction to writing and running tests using Microsoft Playwright. Our SDET Practice went over Playwright’s extensive feature set before diving more in-depth with its API.  

For the workshop, the team went over setup and installation of the tool, as well as wrote a series of comprehensive tests against a test application. Once tests were run, the team afforded participants the opportunity to go over some of Playwright’s advanced features, such as its powerful debugger and enhanced reporting. 

To close out the workshop, SDET Practice Leadership compared Playwright’s features to some of its competitors, went over its pros and cons, and discussed why they believed it to be a paramount tool to consider for automated testing solutions.

Web Workshop (03/24/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

Our Web Practice focused their workshop on their top three, intertwining technologies for development cycles. 

With many modern web applications sharing many of the responsibilities that a middle layer/presentation and service layer/backend provide to the frontend layer, the project was kicked off by organizing the elements with a mono-repository.  

Once the application moved into its build phase, it was time to accelerate the architecture to the next level using NextJS. 

Web Practice Leadership wrapped their project, with an intuitive overview of web bundling and the variety of methods utilized – in order to best adapt to each individual build.

DevOps Workshop (03/29/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

In this workshop, the DevOps Practice demonstrated tools for provisioning infrastructure as well as how to construct a self-servicing platform for provisioning resources. With these new developments in the industry, bridging the gaps between development and ops by allowing developers to self-manage cloud infrastructure to satisfy their needs will be a paramount skill to adopt. Our DevOps practitioners discussed the pros and cons of a number of tools for provisioning infrastructure and identified which tools can best fit a business’ needs.

For the hands-on interactive session, the team ran through the necessary steps to get started with Pulumi and provision a resource onto AWS, along with demonstrating Terraform in order to get a feel for the difference between the two popular infrastructure-as-code tools. After that, we set up some plugins to enhance the development experience with IaC.  

Self-servicing platforms are the best way to allow for engineers to provision resources and infrastructure for their needs en-masse. With Backstage, the team was able to demonstrate a platform for engineers to come to and fulfill their needs whether it be creating a new microservice, a new repository, or even provisioning a new k8s cluster. Furthermore, the provisioning of these resources were proven to standardize and bring uniformity to ensure that best practices are enforced. Long gone are the days of submitting a ticket to create a new instance to deploy an application, with a wait time of a few hours or even a few days.  Self-servicing tools are the future of bringing operations into the hands of developers and bridging the gap between development and operations.

Finally, DevOps Practice Leadership set up a self-servicing platform and hooked it into the aforementioned IaC repository to allow for the provisioning of resources from a GUI. 

Managing infrastructure can quickly become tedious as the number of resources being used on a cloud provider continue to grow.  With infrastructure-as-code, not only DevOps engineers, but developers can now lay out infrastructure using code. Since it’s managed via code, version-controlling/source-code management tools are also available, making management of infrastructure significantly easier.

iOS Workshop (03/28/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

Our iOS Practice did a full overview of Swift Async/Await for iOS application development

Async/Await is a programming feature that simplifies asynchronous operations by allowing software engineers to write asynchronous code in a synchronous manner. It also makes code easy to read/write, improves performance/responsiveness, and reduces the likelihood of errors.

In short, Async/Await is a powerful modern feature in every avenue from development speed and simplified code to and application performance.

Android Workshop (04/11/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

Our Android Practice performed a comprehensive demonstration of the practical integration of Kotlin Multi-Platform Mobile (KMM) for cross-platform development. 

Kotlin Multi-Platform Mobile is an exciting, growing new technology that allows sharing core code between Android, iOS, and Web.  

In this workshop, Android Practice Leadership explored what KMM was, how to setup a project for KMM, a walkthrough implementing a core module to a few APIs (network layer, data models, parsers, and business logic), and then consumed this core library in an Android (Jetpack Compose) and iOS (SwiftUI) application.

Cloud Native Application Development Workshop (04/21/23)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

In this workshop our Cloud Native Application Development Practice introduced the participants to gRPC, which is Google’s take on Remote Procedural Calls. Our Practice Leadership presented a brief history of gRPC and Protocol Buffers. Google and other companies use gRPC to serialize data to binary which results in smaller data packets. Throughout the presentation our team went over some of the pros and cons of using gRPC for individual API calls.

In our hands-on workshop portion participants created a simple application to manage users and notes powered by Java, gRPC, and Postgres. The grand finale featured a full-circle moment as we worked together to create a series of CRUD APIs in Java using gRPC to send/receive data packets, translate those into objects, and store them in a database.

About InRhythm

InRhythm is a leading modern product consultancy and digital innovation firm with a mission to make a dent in the digital economy. Founded in 2002, InRhythm is currently engaged by Fortune 50 enterprises and scale-ups to bring their next generation of modern digital products and platforms to market. InRhythm has helped hundreds of teams launch mission-critical products that have created a positive impact worth billions of dollars. The projects we work on literally change the world.

InRhythm’s unique capabilities of Product Innovation and Platform Modernization services are the most sought-after. The InRhythm team of A+ thought leaders don’t just “get a job,” they join the company to do what they love. InRhythm has a “who’s who” clients list and has barely scratched the surface in terms of providing those clients the digital solutions they need to compete. From greenfield to tier-one builds, our clients look to us to deliver their mission-critical projects in the fields of product strategy, design, cloud native applications, as well as mobile and web development. 

Written by Kaela Coppinger · Categorized: Culture, DevOps, Employee Engagement, Events, InRhythm News, InRhythmU, Java Engineering, Learning and Development, Product Development, Software Engineering, Web Engineering · Tagged: Android, best practices, Cloud Native Application Development, devops, INRHYTHMU, ios, JavaScript, learning and growth, Mobile Development, Press Release 2023, Propel, Propel Workshop, SDET, software engineering, Spring Quarterly Propel Summit, Web

Apr 07 2023

Automating Cloud Infrastructure With Pulumi And Python

Based on a Lightning Talk by: James Putman, Senior DevOps Engineer @ InRhythm on March 29th, 2023 as part of the Propel Spring Quarterly Summit 2023

Author: Mike Adams, Senior Technical Writer @ InRhythm

Infrastructure as Code (IaC)

Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

IaC provides many benefits. It brings the concepts of application development to infrastructure provisioning and allows the provisioning to occur much earlier in the lifecycle as part of application development.

IaC entails source-code management, version control, code-reviews, and collaboration with pull-requests. It allows you to simultaneously maintain multiple cloud providers using hybrid cloud setups to access different services across the major competitors.

With IaC you can provision or destroy your entire infrastructure architecture in one action, allowing different environments to seamlessly represent your architecture.

Other benefits include the ability to modularize infrastructure, thereby increasing its portability and flexibility. Another benefit of IaC is that it allows you to fully automate and easily configure the infrastructure using CI/CD pipelines as that is a part of source code control management.

Introduction To Pulumi

Pulumi is a language agnostic IaC tool used to manage project infrastructure. It provides provisioning of cloud resources and uses a “general purpose language” (GPL), such as JavaScript, GO, Python, etc. to define pipelines in the tool. It integrates easily with GitHub, Azure, AWS, etc., and is an open source package. Pulumi manages the resources.

When compared against Terraform (a similar package of longer standing), Pulumi supports a wider range of conditional options and has more robust utility functions and types. It is easier for developers to use and can integrate with Terraform providers. It supports testing frameworks and Unit, Property, and Integration testing. Unlike Terraform, Pulumi uses the General Purpose Language to describe workflows, while Terraform uses the Hashicorp Configuration Language (HCL).

Because Pulumi is newer than Terraform, as expected the community is smaller and it has less mature documentation. Unrelated to maturity, however, Pulumi provides its state management features behind a paywall. You can, however, manage the state locally or in AWS using an S3 bucket.

Pulumi Projects

Block diagram of Pulumi project architecture.

For our post, the Pulumi Project is the GitHub account that contains the Program, which is the code or repo in that account. The Stacks equate to the branches or environments in the repo and represent different deployment states.

The Program contains the Language Host (part of the Program), which is composed of Resources, the Language Executor, and the Language Runtime. The Resources themselves are binary plugins.

The Language Executor is responsible for launching the Language Runtime, which is in-turn responsible for detecting any Resource registrations changes (i.e., new, removed, updated) and then notifying the Deployment Engine of those changes. The Resources themselves are binary plugins that communicate with the various Providers. Pulumi Resources are stored in ~/.pulumi/plugins.

The Deployment Engine (part of the Pulumi CLI) reads the Notification and verifies that the current Resource States match those listed in the Notification. If the Deployment Engine detects differences, (i.e., a new, modified, or removed Resource), it notifies the Providers which then implement the desired Resource State(s).

The Pulumi SDK provides resource bindings.

Common Commands

Some common commands for working with Pulumi environments are pulumi up to deploy code and resource changes; pulumi stack to manage instances of the project; pulumi config to alter the stack’s config or secrets; and pulumi destroy, to completely tear down the stack’s resources.

Pulumi commands.

Operating Details

This is a python-based demo using a virtual environment. If you have the AWS CLI installed and configured, Pulumi will respect its configuration.

Prerequisites

  • Pulumi CLI
  • Python (v3.7+)
  • An AWS account (i.e., for development, you should also have the AWS CLI installed to simplify your activities)
  • A static website in your IDE to use with Amazon’s S3 website support

Pulumi Setup

Install the Pulumi CLI. Note that you’ll need your Pulumi access token or you must login to the Pulumi website during the setup.

  1. Create a directory location for your project.
  2. CD to that location
  3. Open a terminal in that location and run the following command to create and initialize the Pulumi stack:

pulumi new

Pulumi displays the available cloud/language templates for project scaffolds and offers numerous cloud and language combinations (206 combinations as of 07 Apr 2023). This post uses aws-python.

Pulumi prompts for the project name (the PWD is the default project name), project description, stack name, and cloud region. If you need to create a new stack for this project, simply provide the stack name in “org-name/stack-name” format. If you do not provide the organization name for a new stack, Pulumi associates the stack with the current user. Finally, Pulumi prompts for the cloud region. At this point, Pulumi creates a virtual environment, updates that environment’s toolset, and then downloads and installs the dependencies.

On completion, Pulumi displays, “Your new project is ready to go.”

Pulumi also added the following scaffolding files to your project location:

  • Pulumi.dev.yaml – contains the configuration for the stack you’re initializing
  • Pulumi.yaml – Defines the project
  • __main.py__ – contains a program stub with the Pulumi imports and defines the program’s resources.  __main__.py creates a new S3 bucket and exports the bucket name
  • requirements.txt – contains the Pulumi version requirements
  • venv directory – This directory contains the Pulumi scripts, packages, libraries, and a Python runtime. venv is also a Python virtual environment

Note that the files and their names may vary according to your choice of ‘cloud-language’ combination.

If the AWS CLI is not available, please install it at this time. During the AWS configure step, you will need your AWS Access Key ID and AWS Secret Access Key. You must also know the Output format (if any) and the AWS Region.

At this point, run pulumi up to perform the initial update.

Selecting Yes causes Pulumi to update the modified resource on the AWS site. Pulumi displays the Outputs, the bucket, bucket_name, and website_url, lists a count of the changed and unchanged resources, and the duration of the update.

Pulumi displays sparse details on the proposed update and prompts for confirmation before taking any action. Select details to view a verbose explanation or press CTRL+O (Mac: CMD+O) to open your default web browser to the changes page at the URL shown on the View in Browser (Ctrl+O) line (Mac shows CMD+O instead). Select yes to perform the update or no to abandon the update.

The Outputs reflect the information from your AWS configuration.
bucket : "my-bucket-92bcd61"
bucket_name: "s3-workshop-bucket-0146792"
website_url: "s3-workshop-bucket-0146792.s3-website-us-east-1.amazonaws.com"

The __main.py__ file must import json, mimetypes, and os from Python; import FileAsset, Output, and export from pulumi; and import s3 from pulumi_aws. Additionally, you must define the content_dir to the static website in your project (“www” in the demo) and configure the bucket policy for the static site.

Ensure that you add the appropriate Pulumi libraries to your IDE’s project.

Code

Pulumi-generated __main.py__

This is the file as generated by pulumi new:

"""An AWS Python Pulumi program"""

import pulumi
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket = s3.Bucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket_name', bucket.id)

__main.py__ Modified for the Demo

This is the file modified to add buckets, policies, and a static website.

"""An AWS Python Pulumi program"""

# Setup the imports
import json
import mimetypes
import os
import pulumi
from pulumi import FileAsset, Output, export
from pulumi_aws import s3

# Create an AWS resource (S3 Bucket)
bucket_name = s3.Bucket('my-bucket')

# Export the name of the bucket
pulumi.export('bucket', bucket_name.id)

web_bucket = s3.Bucket('s3-workshop-bucket',
    website=s3.BucketWebsiteArgs(
        index_document="index.html",
    ))

# Set the content directory for the website
content_dir = "www"
for file in os.listdir(content_dir):
    filepath = os.path.join(content_dir, file)
    mime_type, _ = mimetypes.guess_type(filepath)
    obj = s3.BucketObject(file,
        bucket=web_bucket.id,
        source=FileAsset(filepath),
        content_type=mime_type)

# Define AWS buckets
def public_read_policy_for_bucket(bucket_name):
    return Output.json_dumps({
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                Output.format("arn:aws:s3:::{0}/*", bucket_name),
            ]
        }]
    })

bucket_name = web_bucket.id
bucket_policy = s3.BucketPolicy("bucket-policy",
    bucket=bucket_name,
    policy=public_read_policy_for_bucket(bucket_name))

# Export the name of the bucket
export('bucket_name', web_bucket.id)
export('website_url', web_bucket.website_endpoint)

Static Website Files

There are no special changes or requirements for the website relating to Pulumi. Pulumi updates website components during the pulumi up process when the user selects, yes to the update confirmation.

Resources

  • Pulumi
    • Pulumi: https://www.pulumi.com/
    • Pulumi blog: https://www.pulumi.com/blog/
    • Pulumi Slack: https://slack.pulumi.com/
  • Documentation
    • Pulumi Documentation (Main): https://www.pulumi.com/docs/
    • Pulumi Getting Started: https://www.pulumi.com/docs/get-started/
    • Pulumi CLI Reference: https://www.pulumi.com/docs/reference/cli/
  • Community
    • Pulumi Community: https://www.pulumi.com/community/
  • Best Practices
    • Pulumi best practices: https://www.pulumi.com/blog/pulumi-recommended-patterns-the-basics/
  • Repositories
    • InRhythm Pulumi with Python Repo: https://github.com/inrhythm-workshops/pulumi-with-python
    • Pulumi Github Repo: https://github.com/pulumi/

Written by Mike Adams · Categorized: Cloud Engineering, DevOps, Learning and Development · Tagged: AWS, best practices, IaC, Infrastructure as Code, Learning and Development, Pulumi

Apr 04 2023

Playwright’s Reporting And Parallelization Features

Based on a Lightning Talk by: Oleksii Lavrenin, Lead SDET @ InRhythm on March 17th, 2023 as part of the Propel Spring Quarterly Summit 2023

Author: Ted Parton, Lead Software Engineer @ InRhythm

Overview

No alt text provided for this image
Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

We recently held our Spring Summit consisting of six workshops hosted by each of our practice areas. On March 17th, 2023, our SDET Practice led a series of talks and workshops on Microsoft’s Playwright. Playwright is a tool that enables end-to-end testing of modern web applications. Playwright works with all modern web browsers including: Chromium, Firefox, and WebKit. For more information see: https://playwright.dev/

Playwright Parallelism

No alt text provided for this image

Playwright achieves parallelism by running multiple simultaneous processes threads. Each thread runs one Playwright Test File at a time. That is to say, if we have 10 test files and 5 threads, then the Playwright orchestrator will send a test file to each thread (or process), thus running five test files in parallel. As a thread becomes available, it will be provided as part of the next test file.

Tests in a test file are run in order by default. However, it is possible to parallelize those as well; keep in mind that tests run in parallel are in independent processes and cannot communicate with each other. So if one test is dependent on another, you would not want to run them in parallel.

Disabling Parallelism

No alt text provided for this image

You may on occasion have a good reason to disable parallel testing. For instance you may be targeting hardware that has limited process threads, memory, or CPU. Alternatively, there may be a particular workflow you need to follow and it would be best to run in a particular sequence.

Fortunately, Playwright does allow you to disable parallelism by setting the number of workers to one in the `test.describe.configure` settings. You can also do this from the command line runner with `npx playwright test –workers=1`

No alt text provided for this image

Control Test Order

No alt text provided for this image

By default the tests in a Playwright Test File are run in order of declaration. However, you can override that in some circumstances. For instance if you have disabled parallelism, test files will be run in alphabetical order by default. So you could control the order by coming with a good naming convention.

You can go a step further by controlling the order in helper functions. For more information on that, we recommend that you see the documentation located at: https://playwright.dev/docs/test-parallel#use-a-test-list-file

Playwright Reporting

No alt text provided for this image

Playwright Test includes the ability to create reports based on test results. Playwright includes seven predefined reporters and provides support for creating custom reporters.

The Predefined Reporters Are:

  • List Reporter

Prints a line for each test being run, and is the default for all executions except when running with CI. For CI the Dot reporter is the default.

Example Output:

No alt text provided for this image
  • Line Reporter

According to the official documentation, a Line Reporter is more concise than the List Reporter. It uses a single line to report the last finished test, and prints failures when they occur.

Line Reporter is useful for large test suites where it shows the progress but does not spam the output by listing all the tests.

Example Output:

No alt text provided for this image
  • Dot Reporter

The Dot Reporter provides a concise report by just producing a single character per successful test. The Dot Reporter is the default reporting method for CI. This method can be very useful anytime you do not want a lot of output.

Example Output:

No alt text provided for this image
  • HTML Reporter

As its name suggests, the HTML reporter generates an HTML based report. The HTML Reporter according to the documentation, by default, HTML reports are opened automatically if some of the tests failed. You can control this behavior via the open property in the Playwright config. The possible values for that property are always, never and on-failure (default).

You can also configure host and port that are used to serve the HTML Report.

  • JSON Reporter

This reporter generates results in JSON (JavaScript Object Notation). You may find it useful to have this written to a file rather than the screen. 

Below is an example of how to do this from Bash:

No alt text provided for this image

Alternatively you can define this behavior in the configuration file:

No alt text provided for this image
  • JUnit Reporter

This will produce a report in JUnit-style xml. As with the JSON Reporter, you will likely want to write this out to a file. The JUnit Reporter offers support for a robust set of options. If you are testing an app written in Java that utilizes JUnit for tests, this reporter can be highly useful. 

More information about this can be found at: https://playwright.dev/docs/test-reporters#junit-reporter

  • GitHub Reporter

Provides automatic failure annotations when running in GitHub actions. The other reporters work with GitHub Actions, but do not provide annotations.

Invoke A Reporter

No alt text provided for this image

It is quite easy to specify which reporter to use, by setting the name like in the example below:

No alt text provided for this image

Custom Reporters

No alt text provided for this image

As previously mentioned, you can create a custom reporter. Playwright provides an API to help with this at https://playwright.dev/docs/api/class-reporter. 

Below is an example of a custom TypeScript reporter courtesy of the Playwright website:

No alt text provided for this image

As with the pre-defined reporters, you can use your custom ones by specifying the name of the reporter. For instance, the custom reporter above can be accessed as:

No alt text provided for this image

Written by Kaela Coppinger · Categorized: DevOps, Software Engineering, Web Engineering · Tagged: best practices, devops, INRHYTHMU, JavaScript, learning and growth, Microsoft, parallelization, Playwright, Propel Spring Quarterly Summit 2023, Propel Workshop, reporting, software engineering, testing

Mar 30 2023

A Comprehensive Guide To Playwright’s Debugging And Tracing Features

Based on a Lightning Talk by: Alex Kurochka, Senior SDET Engineer @ InRhythm on March 17th, 2023 as part of the Propel Spring Quarterly Summit 2023

Author: Ted Parton, Lead Software Engineer @ InRhythm

Overview

No alt text provided for this image
Design Credit: Joel Colletti, Lead UI/UX Designer @ InRhythm

We recently held our Spring Summit consisting of six workshops hosted by each of our practice areas. On March 17th, 2023, our SDET Practice led a series of talks and workshops on Microsoft’s Playwright.

Playwright is a tool that enables end-to-end testing of modern web applications. Playwright works with all modern web browsers including: Chromium, Firefox, and WebKit.

In this article, we will go over three tools to go over debugging with Playwright:

  • Playwright Inspector
  • Playwright Test For VSCode
  • Trace Viewer

Fixtures

No alt text provided for this image

Before we get into specific tools, let’s talk about Playwright Fixtures.

For those unfamiliar with test fixtures, these can be useful in establishing an environment for each test. That is, a fixture can provide everything a test needs to run. It is recommended that your fixtures provide only the absolutely necessary things to run and nothing else. In Playwright, fixtures are isolated between tests. With fixtures, you can group tests based on their meaning, instead of their common setup.

According to the official Playwright documentation (source: https://playwright.dev/docs/test-fixtures), Fixtures have a number of advantages over before/after hooks:

  • Fixtures encapsulate setup and teardown in the same place so it is easier to write
  • Fixtures are reusable between test files – you can define them once and use them in all your tests. That’s how Playwright’s built-in page fixture works
  • Fixtures are on-demand – you can define as many fixtures as you’d like, and Playwright Test will setup only the ones needed by your test and nothing else
  • Fixtures are composable – they can depend on each other to provide complex behaviors
  • Fixtures are flexible. Tests can use any combination of the fixtures to tailor the precise environment they need, without affecting other tests
  • Fixtures simplify grouping. You no longer need to wrap tests in describes that set up environment, and are free to group your tests by their meaning instead
No alt text provided for this image

Playwright Inspector

No alt text provided for this image

Playwright Inspector is the default debugging tool for Playwright. While Playwright scripts typically run in a headless mode, Playwright Inspector has a GUI to help troubleshoot your script which opens during the test run along with the browser that opens in headed mode.

To enable it we add a `–debug` to our command line. You can specify which test to run by adding `-g “test name”`. See our example below:

No alt text provided for this image

 When you run tests in debug mode, VSCode will open up the Playwright Inspector window, which will show the code to be executed and the debugger, such as the image below:

No alt text provided for this image

Once we have started our application with Playwright debugging on, we can step through the code in the Playwright Inspector and choose when to use our Fixtures for our tests. You can also let the tests play, and if it will stop at any part that breaks. From there you can look at the error report generated by Playwright. The error report can include lots of useful information such as timeouts, missing variables, unexpected results, etc. In addition to the report you can also view the results in the terminal from VSCode. 

See below for an example:

No alt text provided for this image

With Playwright Inspector you can set breakpoints to help you debug., You may find it helpful to add a breakpoint on a line before the line you know is broken. Breakpoints should be set in code with the await page.pause() statement. This will give you the ability to look at current variables and settings before you get to the line you are attempting to diagnose. But where Inspector truly shines is helping you debug the web page document object model (DOM).

The browser console can be used to debug locators while running tests in debug with playwright inspector. A javascript ‘playwright’ object can be used to evaluate different locators while the test run stopped at a breakpoint. To test locators use ‘playwright’ object methods like: playwright.locator(“string-locator”) and playwright.inspect(“string-locator”).

Playwright Test For VSCode

No alt text provided for this image

Playwright Test for VSCode is a plugin that helps you integrate Playwright into your VSCode workflow. According to Microsoft, this plugin can:

  • Install Playwright
  • Run Tests With A Single Click
  • Run Multiple Tests
  • Show Browsers
  • Pick Locators
  • Debug Step-By-Step, Explore Locators
  • Tune Locators
  • Record New Tests
  • Record At Cursor

You can install this extension by clicking on the extension tab/button in VSCode, then search for “playwright.” Click on the one that says “Playwright Test for VSCode” by Microsoft.

No alt text provided for this image

Once installed it will scan your project for all of your tests and group them together. With this integrated into VSCode, a play button will now appear beside tests in your test files. This makes it much easier to start and debug than with Playwright Inspector where you need to use a command line.

Additionally this adds a Playwright panel to VSCode that makes it easier to toggle options such as should your test run in headless mode or not. In short, this plug-in adds in a lot of nice features designed to provide a better user experience for testers.

Trace Viewer

No alt text provided for this image

Finally we have a Trace Viewer. Playwright Trace Viewer is a GUI tool that helps you explore recorded Playwright traces after the script has run. You can open traces locally or in your browser on trace.playwright.dev.

There are a couple of ways to enable the trace viewer. First the command line, where you add the option, `–trace on` or you can go to the Playwright settings file and enable (or disable) it there. 

Results are stored in a trace folder. To open a trace via the command line you enter, `playwright show-trace <path-to-file>` and hit ENTER. The trace viewer provides you with a lot of detailed information such as page load times, calls to resources, and which Javascript functions are being called.

Closing Thoughts

No alt text provided for this image

In conclusion, though each of these tools has its pluses and minuses, utilizing a combination of all three can help you take your diagnostics to a whole new level.

Written by Kaela Coppinger · Categorized: DevOps, Software Engineering, Web Engineering · Tagged: best practices, debugging, devops, INRHYTHMU, learning and growth, Microsoft, Playwright, Propel, Propel Spring Quarterly Summit 2023, Propel Workshop, software engineering, Tracing

Mar 23 2023

How To Write A Good Pull Request

Overview

No alt text provided for this image

Pull Requests are the backbone of open source software development. They allow contributions by anyone, from anywhere. PRs are also a vital form of communication, even within a localized development team working on proprietary software.

What makes a good Pull Request?

Let’s break it down into 4 Rules Of Thumb:

  • Provide Context
  • Make It As Small As Possible, But Not Any Smaller
  • Take Screenshots
  • Ask For Assistance

Provide Context

No alt text provided for this image

Providing context is an important first step in guiding the reviewer. Use this as an opportunity to explain why you are making this change. This can be as simple as referring to the bug/defect/issue number, and as detailed as necessary to describe your change.

In this example, there is a provided link to an original issue on the npm.community site and linked directly to the source of pnpm that was referenced in the original issue.

No alt text provided for this image
https://github.com/npm/cli/pull/32#issue-204418739

In this more complicated example, one wants to make sure I was consistent with how other PRs were made to this repository. One of the suggestions is the old “when in Rome” rule. Some repositories even provide a template, which can be helpful, but this one didn’t. So, one should make each item discussed in the issue into a bullet item, checking-off the ones that were completed and noting anything that you’re not sure about.

No alt text provided for this image
https://github.com/npm/cli/pull/61#issue-211591081

Make It As Small As Possible, But Not Any Smaller

No alt text provided for this image

Everyone agrees that smaller PRs are easier to review. Sometimes it’s just not possible to make a very small change, so here’s some practical advice: don’t do more than necessary. If you need to stray from the core of the change you are making, separate it.

For example – imagine you are adding a path through the code to handle a new requirement. Along the way you realize that some of the variables and functions could use better names, but changing those means that you now need to update a bunch of files in another area of the code. STOP! Don’t make that change! Or at least, don’t bunch it together with your other changes. Instead, make the rename change in its own commit, and probably in its own Pull Request too. In the PR you can explain why you are making the change and how it simplifies the real change you want to make easier.

This same strategy should be applied to most whitespace and re-factorings you want to do during the course of implementing a new feature or resolving a defect. Be considerate of the reviewer’s time. There is nothing more frustrating than hunting through all the changes looking for the actual change and bumping into whitespace and “re-namings” spread across many files.

Take Screenshots

No alt text provided for this image

So you’re working on a story that affects the UI? Maybe you are fixing alignment in IE11, or adding a new interstitial modal when the user clicks a button. The code will get reviewed as it always does, but many people struggle with visualizing layout changes or CSS tweaks. Include a screen capture of the before and after. It’s usually pretty easy to get a before shot – just use the QA or production environment. Then for the after shot, use your local server. Both GitHub and Atlassian BitBucket allow you to paste images, so you can literally SHIFT-CTRL-CMD-4 (OSX) to copy a section of the screen to your clipboard, then CMD-V to paste it into the input box of your PR description.

Another incredibly helpful option is to use an application like GIPHY Capture to record an animated GIF that can be added to your PR. These are great for when you want to show an animation or a sequence of steps.

Let’s face it, it’s a pain for the reviewers to fire up their Windows vm to try out your change that resolves an Edge problem. Make their life easier by including an animated GIF that shows exactly what changed right in the Pull Request!

Ask For Assistance

No alt text provided for this image

Become a big fan of the quote “it is better to beg for forgiveness rather than ask for permission.” In so many instances, not just in software, this rule helps save time. But making too big a change in your PR may be received poorly, especially when you are not a regular contributing member.

Be cautious and curious in order to lead a better engagement and ultimately, a better solution.

Here is a comment made on a PR to a tslint project. You can see how the person’s comment/feedback is acknowledged and further asks a clarifying question because of the impact it would have on so many files. This lets the reviewers know that you have respect and consideration for the size changes coming into their code base, and also that you want to be collaborative in finding the best solution.

No alt text provided for this image
https://github.com/palantir/tslint/pull/1738#issuecomment-261527450

Closing Thoughts

What other things do you like to do in your PRs? What kinds of things would you like to see more of in PRs that you are reviewing? What would you like to see less of?

No alt text provided for this image

Written by Kaela Coppinger · Categorized: DevOps, Java Engineering, Product Development, Software Engineering · Tagged: agile, best practices, growth, INRHYTHMU, JavaScript, learning and growth, software engineering

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

Footer

Interested in learning more?
Connect with Us
InRhythm

110 William St
Suite 2601
New York, NY 10038

1 800 683 7813
get@inrhythm.com

Copyright © 2023 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT