Use HAR Files for:

• Complex, multi-step requests that involve multiple network calls

• Requests with dynamic data, such as timestamps or session IDs

• Testing scenarios where the actual API response matters

When using HAR files, it's essential to sanitize the recorded traffic to ensure that sensitive information is not leaked. Santization techniques can be used to remove sensitive data from the HAR file, such as:

• Masking sensitive information like passwords, API keys, user tokens or credit card numbers

• Removing personal identifiable information (PII) like names and email addresses

• Redacting unnecessary details that don't affect the test outcome

Recording actual network traffic using HAR files allows you to test your application's behavior in a more realistic way. This approach is particularly useful when testing scenarios that involve multiple requests with complex dependencies or error handling.

Use Mocking for:

• Simple, single-response APIs that don't require complex setup or tear-down logic

• Testing specific API responses without worrying about the underlying network calls

• Rapidly prototyping or testing individual API endpoints

Mocking a specific API response enables you to quickly test and validate your application's behavior against a known, expected response. This approach is ideal for simple APIs or when you need to focus on a single endpoint.

Mocking Multiple API Requests

Instead of using HAR files, you can also use mocking to simulate multiple API requests. This approach allows you to control the responses for each request individually, which can be useful when testing complex scenarios that involve multiple API calls.

For example, you could mock the response for an initial API request, then mock the response for a subsequent API request based on the result of the first request. This way, you have more flexibility and control over the testing process.

Pros and Cons

Using mocking to simulate multiple API requests has its pros and cons:

• Pros:

  • More control over the testing process

  • Can be useful when testing complex scenarios that involve multiple API calls

  • Allows for easier error handling and scenario setup

• Cons:

  • Requires more code and setup effort compared to using a HAR file

  • May lead to more complexity in your test code if not managed properly

In Summary

When you need to test complex, multi-step requests or dynamic data scenarios, use HAR files. For simple, single-response APIs or rapid prototyping, use mocking. By understanding the strengths and weaknesses of each approach, you can choose the right method for your testing needs and ensure that your application behaves as expected in various scenarios.

Next, you'll want to sanitize your HAR file to remove any sensitive information that could compromise security. This includes:

• Authorization headers and tokens

• Traceparent and IP addresses

• x-* headers (and any other headers you deem private or sensitive)

You can use tools like https://har- sanitizer.pages.dev/ or https://github.com/google/har-sanitizer to sanitize your HAR files. For a deeper dive into how sanitization works, you can check out the code at https://github.com/cloudflare/har-sanitizer/blob/main/src/lib/har_sanitize.tsx

Finally, save your sanitized HAR file in a folder and update your Playwright code using the following as reference:

Docs: https://playwright.dev/docs/mock#mocking-with-har-files

await page.routeFromHAR(filePath, {
  url: '**/graphql',
  update: false
 });
await page.reload();

Test and Optimize:
After setting up your HAR files, run your tests to ensure everything is working as expected. Use the results to optimize your tests and improve their efficiency.

Using Fixtures:
If you're using fixtures to manage your test data, you can add the following code to get started:

Fixture Code for reference:

export const applyHarFileMock = async (page: Page, filePath: string) =>
  await page.routeFromHAR(filePath, {
    url: '**/graphql',
    update: false,
  });

Usage code for reference:

test.use({
  storageState: "<path>",
  actionTimeout: 2000,
  mockFromHarFile: './e2e/har-files/sanitized_replay_har.har',
});

Note that this code should be tailored to your specific use case and testing environment.

 {
      use: {
        bypassCSP: true, // add this to disable cors
        launchOptions: {
          args: ['--disable-web-security'], // add this to disable cors
        },
      },
    }

• Staff Engineer by Will Larson

• Life 3.0 by Max Tegmark

• Smart Money Strategy by Luke Smith

To update the global user agent in Playwright, refer to the following code snippet. Please adapt your global setup function using this as a guide:

 const config = GlobalConfiguration.getInstance({}),
    browser = await config.getConfig().getBrowser(),
    context = await browser.newContext({
      ...config.getPlaywrightConfig().use,
      userAgent: 'made-up-user-agent',
    });
 await context.tracing.start({ screenshots: true, snapshots: true });
 const page = await context.newPage();
  await context.tracing.stop({
    path: './<trace-file-name>.zip',
  });
  await browser.close();

It took me nearly a decade to grasp and articulate my salary expectations and requirements clearly. Throughout this journey, my understanding of PAY has deepened and evolved.

The interpretation of what PAY means has evolved and will keep evolving.

Sources such as :

• Kalzumeus salary negotiations

• George Stocker's salary progression

• The internet in general

have helped me navigate this labyrinth.

Most of the articles I have read have been predominantly of US-based companies.

This helped me understand expectations and also confused me, because the pay structures and offerings in the US are different compared to other countries such as India & Australia, among others.

To discern whether I align with or deviate from industry norms, I've relied on statistical analyses, drawing from sources like the Stack Overflow Developer Survey and data on salary distributions, perks, and work-life balance from peers across tech companies in similar fields. Conversations with recruiters have also shed light on the job market, pay scales, and benefits.

Sources used for these calculations are :

• Stack Overflow Developer Survey

• Salary Distribution (including perks provided at a workplace + work-life balance), among peers across different tech companies in the same discipline

• Inputs from Recruiters around what jobs are out there and pay structures + perks for those aforesaid jobs.

Assumptions are taken while making this analysis:

• PAY = MONETARY SUM + PERKS + WORK-LIFE BALANCE

• Not all opportunities are equal

• One cannot just have an amazing career progression over some time, without being paid well. I have seen enough examples of it. You are free to disagree with this. You must not be an asshole/sexist/racist or any similar word or synonym.

P.S.: Work-life balance, while integral, transcends mere job perks due to its subjective nature.

Let's now just talk about the Skills because this is the one of key factors which affect your PAY, the others being :

• Work Ethic & Attitude

• EQ + IQ

• Interpersonal + Intra Personal Skills & Intelligence

If Potential Future Pay (let's say PFP for ease) can be represented as a function, it could be described loosely by the below equation :

• PFP current = Pay for Skills you bring to the table * relevance_factor of those skills * expertise_factor

• The relevance_factor of those skills can also be termed as the Perceived value of those skills

• Bargaining Power = expertise_factor(skills) * Relevance_factor(skills) * demand_factor of those skills

• PFP future = PFP current * Bargaining Power + Perks at Job + Work-Life Balance

Things to consider while thinking about your PFP future :

• Depending on the opportunity and your skills, you can deviate " + or - of 7.5 % "

• When you think about Work-Life Balance, put a monetary value against it. Think of it as a $$ value you want to travel that extra 30 mins every day or whatever you feel is your work-life balance factor.

• Luck is a small factor but not too small to ignore

• It is easier to bring the skills from your initial opportunities & quality of those opportunities

• Self Learning helps a lot, especially in cases where your job doesn't provide you with the kind of things you want to work on. If you identify yourself in such a situation then start doing the required remedial work, to ensure the quality of your skill improves over time.

• Having a mentor helps, but isn't always required. Enough great role models/mentors on the internet to help out. You define your parameters for performance and own it.

• Discussing your salary with people whom you trust in the same sphere of work helps, to know where you are. This is not always easy and you may get burnt sometimes. For me, it was a real eye-opening experience, mostly positive.

Market / Industry standards may not always help you in the negotiations. If you are getting paid below the "market/industry standards" you are severely underpaid, because I believe the standards in Software industry are skewed towards the lower end.

Conclusively, if you find yourself in a learning-rich yet lower-paying role, set a time limit on this phase. Continuous learning and skill enhancement are paramount. Always be collecting data, reassessing, and adapting.

Here's to navigating the complexities of compensation with insight and strategy. Cheers!

I intend this to be a personal benchmark - a reference point to revisit and gauge my progress over time. It aims to serve as a rubric, a structured framework for evaluation and improvement.

Guidelines :

• Do you understand the concepts of

  • Test Pyramid

  • CI /CD

  • Behavior-Driven Development (BDD)

  • Test-Driven Development (TDD)

  • Writing Unit tests, Integration tests and E2E tests . Identifying the differences between them.

• Language Proficiency: :

  • How comfortable are you with a given language e.g. : Java , Python , Scala, Erlang

  • Do you understand how to manage dependencies effectively and tooling provided for it in that particular language ecosystem.

  • Have you written / developed a working proof concept for the test automation framework.

  • Is there a way to enforce coding standards : Code Style Guides.

• Cloud & Containers & Everything in between

  • Unlike 5 years ago, now we have Docker & the cloud offerings (GCP & AWS, etc.) have matured significantly. Hence, knowing these skills are important. The reasons being, more often than not,

    • You work in a team.

    • The technical skills you pick up are easily augmented by real world experience. You can gain nuance and context around technical implementation. This is true for any skill, not just this particular one.

  • Rate yourself on

    • Comfort level with a Cloud Provider(s). You can always go for more.

    • Spinning up Jenkins or Buildkite based CI/CD solution. First manually and then via code.

    • Kubernetes Expertise and Usage.

• Have you written an

  • API Test Automation Framework

  • UI Test Automation Framework

  • Performance / Load Test Automation Framework (backend)

  • Front End Performance Test Automation Framework

  • Mobile Test Automation Framework from scratch using the below as guidelines

  • Did you use any design patterns and coding principles (SOLID, Page Object, Clean Code)

  • Dependency Management

  • Exception Handling

  • Test Reporting

  • Parallelisation

  • Improving Determinism of the api tests

  • Using a hermetic environment ( via containers) to improve determinism and speed up the tests further more.

  • Run the API tests in CI

  • Synthetic Production monitoring i.e. run tests in prod to ensure a business workflow is functioning.

• Communication Skills

• Mobile Testing

  • Figure out reasons when to go native approach such as Espresso and XCUITest & when to go something like Appium

  • CI/CD such as Bitrise.io

  • Comfort level around how app deployment and distribution works for an mobile ecosystem and any costs associated around it.

• Resources to you use for learning and Exploring

  • Nothing like a real world implementation

  • YouTube Channels, Conferences & Talks

  • Blogs

  • Tech Guides

  • Documentation

  • GitHub

  • Follow people on twitter, from whom you can learn.

  • Experiment and fail. You learn a lot from failures.

One can build a mind map for each language ecosystem essentially, using the above info. Build yours and keep track of it.

• P.S. : Feedback is always welcome. You can tweet to me at : @vaikuntj .

- Identifying the needs and dependencies of testing & related activities early in the planning cycle. This means understanding the following :

• Dependencies of testing

  • Within a team

    • Technical activities/experiments

    • Understanding the business requirements and plan accordingly

  • Outside of teams

    • Data that comes from other squads and teams

    • Impact on teams that depend on us for

• A continuous feedback loop to react to changes and feedback

• Automate your tests and ensure the tests are not flaky !!!

  • If there are flaky tests then, the confidence in the system goes down

How to implement the Shift Left process ??

• Understand where you are in the journey

• Make measurable changes

  • See how you can measure progress. It could be

    • Bugs that are caught earlier in the process

    • Issues prevented

    • Coverage of automated tests ==> behaviors tested

    • Confidence a team has with releases

    • How easy is it to integrate feedback

• The least disruptive way is to introduce changes incrementally (this works in most cases). Depending on the context, one may do it with a more big-bang approach

• See what the team is comfortable with and what you are trying to achieve

• The goal is to improve iteratively. It is okay to have a non-perfect start, as long as you improve the process and execution, you are good !!!!

Imagine managing 500 Playwright tests for your application. A strategic approach to handle this scenario involves several steps to improve efficiency and reduce runtimes.

Categorizing Tests for Parallel Execution

• Firstly, categorize the 500 tests into 4 or 5 distinct groups based on the features they test. By doing so, you can execute approximately 100 tests simultaneously across each category. This method not only accelerates the testing process but also localizes any failures to a specific block of 100 tests, streamlining the debugging process.

• Optimizing Authentication Flows

  In scenarios involving authentication, leverage fixtures to reuse authentication states, eliminating the need to log in for every test. This adjustment can significantly decrease the time required for each UI test.

• Leveraging Docker for Consistent Environment

  Containerizing the testing environment ensures consistency across different machines and simplifies the setup process for new testing instances.

Utilizing GitHub Actions for Test Parallelization

• GitHub Actions offers a convenient way to parallelize tests, further enhancing efficiency and reducing test execution times.

Running Tests on Optimized Infrastructure

• Deploy your tests on a memory-optimized EC2 instance, such as a c5.4xlarge, allowing for up to 12 tests to run in parallel. Optimize costs by employing a combination of on-demand and spot instances, tailoring the infrastructure to your specific workload requirements.

• Through these strategic measures, you can significantly improve the speed and efficiency of your Playwright testing suite, ensuring rapid feedback and high-quality software delivery. Use the following code for reference:

•         FROM mcr.microsoft.com/playwright:v1.37.0
  
          RUN mkdir -p /opt/google/chrome
          RUN ln -s /ms-playwright/chromium-1048/chrome-linux/chrome /opt/google/chrome/chrome
          RUN npm uninstall -g yarn && \
              apt-get remove -y nodejs python3 --purge && \
              apt-get update && \
              apt-get install -y openjdk-11-jre uuid-runtime  && \
              apt-get autoremove -y && \
              apt-get clean -y && \
              rm -rf /var/lib/apt/lists/*
  
          # Remove unused browser
          RUN rm -rf /ms-playwright/firefox-* /ms-playwright/webkit-*
  
          # Install nvm with node and npm
          RUN mkdir -p /usr/local/nvm
          ENV NVM_DIR /usr/local/nvm
          ENV NODE_VERSION v16.19.1
          RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.2/install.sh | bash
          RUN /bin/bash -c "source $NVM_DIR/nvm.sh && nvm install $NODE_VERSION && nvm use --delete-prefix $NODE_VERSION"
  
          # Add node and npm to the PATH
          ENV NODE_PATH $NVM_DIR/versions/node/$NODE_VERSION/bin
          ENV PATH $NODE_PATH:$PATH
  
          WORKDIR /app
  
          RUN npm install -g yarn --loglevel silent
          RUN wget https://repo.maven.apache.org/maven2/io/qameta/allure/allure-commandline/2.17.2/allure-commandline-2.17.2.tgz
          RUN tar -xvzf allure-commandline-2.17.2.tgz && rm -rf allure-commandline-2.17.2.tgz
          ENV PATH /app/allure-2.17.2/bin:$PATH
  
          RUN yarn install --cache-folder ~/.cache/yarn --frozen-lockfile --ignore-scripts
  

• Simulating the API responses for third-party integrations

  • After implementing these adjustments, consider simulating the API responses for third-party integrations next. This strategy effectively eliminates a significant source of test instability.

  • To maintain the integrity of these simulated responses, it's crucial to validate that the mock data accurately reflects real API structures. Utilizing tools like Zod can help enforce consistency by verifying that the response structure remains unchanged over time.

Remember, refining and enhancing the efficiency of your pipeline is an ongoing endeavor. Continuous evaluation and optimization are key to maintaining a swift and reliable testing process.

One such use case is :

• Ensuring user analytics (e.g. Segment) is not triggered for your automated test cases. Not doing this may result in a higher analytics bill.

Solution:

The solution is to update your config and leave the tests untouched.

Config for WebdriverIO BrowserStack Run

export const config: WebdriverIO.Config = {
  runner: 'local',
  specs: ['./features/**/*.feature'],
  exclude: [],
  maxInstances: 2,
  capabilities: [
    {
      'bstack:options': {
        os: process.env.OS_NAME || 'OS X',
        osVersion: process.env.OS_VERSION || 'Big Sur',
      },
      browserName: 'Chrome',
      browserVersion: 'latest',
      'goog:chromeOptions': {
        args: ['user-agent=madeup-user-agent-name'],
      },
    },
  ],
}

Config for WebDriverIO Local Run

export const config: WebdriverIO.Config = {
  runner: 'local',
  specs: ['./features/**/*.feature'],
  exclude: [],
  maxInstances: 10,
  capabilities: [
    {
      maxInstances: 1,
      browserName: 'chrome',
      acceptInsecureCerts: true,
      'goog:chromeOptions': {
        args: ['user-agent=madeup-user-agent-name'],
      },
    },
  ],
}

Config for Playwright Local Run

const config: PlaywrightTestConfig = {
   use: {
    ignoreHTTPSErrors: true,
    contextOptions: {
      bypassCSP: true,
      recordVideo: {
        dir: 'e2e/videos',
      },
      userAgent: 'madeup-user-agent-name',
    },
    headless: true,
    screenshot: 'only-on-failure',
    trace: 'on',
    video: 'retain-on-failure',
  },
};
export default config;

Config for Playwright Docker Run

import { PlaywrightTestConfig } from '@playwright/test';

const config: PlaywrightTestConfig = {
  use: {
    headless: true,
    navigationTimeout: 30000,
    actionTimeout: 10000,
    screenshot: 'only-on-failure',
    ignoreHTTPSErrors: true,
    contextOptions: {
      bypassCSP: true,
    },
  },
  projects: [
    {
      name: 'Chrome',
      use: {
        browserName: 'chromium',
        contextOptions: {
          ignoreHTTPSErrors: true,
          userAgent: 'madeup-user-agent-name',
        },
      },
    },
  ],
};
export default config;

Resources

• https://github.com/microsoft/playwright/issues/11829

function gsearch(){ 
git log -3 -i --grep="$1" --pretty=format:'%h %s [%an]'
}

Usage :

gsearch wip

• Learning Typescript
• Practical Pair Programming

• Dark Matter

• Recursion

If you have got any book suggestions tweet to me vaikuntj

• Git Clean: Cleans the working tree by recursively removing files

git clean [--dry-run]

• Git CherryPick: Apply the changes introduced by some existing commits

git cherry-pick <SHA-ID>

• Docker + protractor docs
• New Relic Synthetics Manager forked
• Incorrect deviceName is displayed in allure reports
• Outdated documentation: "Fresh browser per test"
• Update docs to reflect removal of find_element_by for 4.3
• Update docs to make page loading strategy more readable & easy to approach

Question: How can you execute tests from both tags using a single command?

Solution: To run both sets of tests in a single command, one can use the following syntax:

yarn test:pw --grep "@Prod-UI | @PR-push"

Here's a breakdown of the command:

• yarn test:pw initiates the test command.

• --grep "@Prod-UI | @PR-push" filters the tests to include only those with the @Prod-UI tag or the @PR-push tag.

Additionally, the yarn test:pw command is configured as follows:

ALLURE_RESULTS_DIR=e2e/allure-results playwright test e2e --headed 
--config e2e/pw.local.config.ts

This configuration sets the directory for Allure test results, runs the tests in a headed mode (with a visible browser), and specifies the test configuration file to use.

A better way to view commit history

git log --pretty=format:"%h - %an, %ar : %s" -6

Time limiting the logs you see

git log --pretty=format:"%h - %an, %p %ar : %s" --since=2.weeks

git log --pretty="%h - %s" --since="2022-01-01" --before="2022-06-01"

git restore is an alternative to git reset

Unstaging a Staged File with git restore from Git v2.23 onwards**

git restore --staged README.md

• WebDriverIO

• CucumberJS

• TypeScript

This works with parallel test runs too.

WebdriverIO Allure Docs here

const allure = require('allure-commandline');
require('dotenv').config();

export const hooks = {
  afterStep: function (step, scenario, { error, duration, passed }, context) {
    if (error) {
      browser.saveScreenshot('results/allure-results/afterStepScreenshot.png');
    }
  },
  onComplete: async function () {
    const reportError = new Error('Could not generate Allure report');
    const generation = allure([
      'generate',
      'results/allure-results',
      '--clean',
      '--output',
      'results/allure-reports',
    ]);
    return new Promise<void>((resolve, reject) => {
      const generationTimeout = setTimeout(() => reject(reportError), 10000);

      generation.on('exit', function (exitCode) {
        clearTimeout(generationTimeout);

        if (exitCode !== 0) {
          return reject(reportError);
        }

        console.log('Allure report successfully generated');
        resolve();
      });
    });
  },
};