DEV Community: Harshad Lambate

workday-autofill – fill Workday/Lever/Greenhouse job applications once, reuse your answers everywhere

Harshad Lambate — Fri, 30 Oct 2026 04:53:37 +0000

Every company on Workday = new account + the same 7 pages again: name, address, work experience, education, "how did you hear about us", notice period, sponsorship...

workday-autofill:

fills Workday, Lever and Greenhouse applications from your profile
asks each new question once and remembers it everywhere
runs multiple applications in parallel, with a queue
wdautofill search finds recent jobs on company career sites for your city + keywords
per-company cover letter from your template
never clicks Submit — you review everything
Runs locally, no subscription. AI optional (free Groq/Gemini or offline Ollama).

Early version — built it during my own job search. If a site doesn't fill, open an issue with the debug file and I'll fix it.

Repo: https://github.com/HarshadLambate/workday-autofill

I built a free HTML test reporter for Playwright, Jest, Vitest and Cucumber.js that automatically captures API calls, screenshots and retries

Harshad Lambate — Mon, 19 Oct 2026 05:24:01 +0000

When a test fails in CI, I usually end up asking the same questions:

What did the API actually return?
What was on the screen when it failed?
Did it fail on the first try, or only on the retry?
Is this test flaky, or did something really break?

The default reports show the assertion and the stack trace, so the rest means adding console.logs, rerunning locally, or digging through traces.

So I built Ace Reports: one self-contained HTML file per run, with all of that captured automatically. It already existed for .NET, Java and Python, and it’s now on npm for TypeScript/JavaScript.

Live demo report: https://harshadlambate.github.io/AceReportsWebsite/demo.html

What it captures, without changing your tests
Every API call: method, URL, request and response bodies, status and duration. It hooks Node’s http/https and the global fetch, so it covers axios, fetch, got, supertest, node-fetch, ky and Playwright’s request fixture. It also covers calls made through your own API client wrappers and vendor SDKs, with nothing to wrap. Authorization and cookie headers are redacted.
A screenshot on failure, taken before teardown closes the browser. It finds the page by itself: Playwright’s page fixture, a Vitest test.extend page, a Cucumber World’s this.page, or the jest-playwright global.
Retries and flaky tests: every attempt is its own tab with its own logs, error, API calls and screenshots. A test that passes after a failed attempt is marked flaky instead of quietly showing green.
Logs:
Playwright test.step, actions and expects.
Cucumber Given/When/Then steps, with doc strings and data tables.
console.log output, placed under the test that wrote it.
Search, filters and categories: filter by status or tag, search by name, and click a category bar to narrow the table.
One HTML file, no server: attach it to a ticket, email it, or keep it as a CI artifact.
How to use it

Playwright Test: one line.

// playwright.config.ts
reporter: [['list'], ['@acereports/playwright']],

Jest: two lines.

// jest.config.js
reporters: ['default', '@acereports/jest'],
setupFilesAfterEnv: ['@acereports/jest/setup'],

Vitest: two lines.

// vitest.config.ts
test: {
  reporters: ['default', '@acereports/vitest'],
  setupFiles: ['@acereports/vitest/setup'],
}

Cucumber.js: two lines.

// cucumber.js
plugin: ['@acereports/cucumber'],
requireModule: ['@acereports/cucumber/support'],

Install with npm i -D @acereports/playwright (or /jest, /vitest, /cucumber). Run your tests as usual, and the report is written to TestResults/AceReport_.html.

To add your own lines or screenshots:

import { ace } from '@acereports/playwright';

ace.info('Submitting payment');
await ace.takeScreenshot('After login');

Retries come from what you already use: Playwright retries, jest.retryTimes, Vitest retry, or cucumber-js --retry. Parallel workers end up in one report.

Limitations
It doesn’t see HTTP/2 calls made with the http2 module, or gRPC.
Vitest is supported in Node mode only, not browser mode.
Requires Node 18+, Playwright 1.40+, Jest 29+, Vitest 3+ and Cucumber.js 10+.

It’s free to use, including at work.

Website: https://harshadlambate.github.io/AceReportsWebsite/
npm: https://www.npmjs.com/package/@acereports/playwright

I’d really like feedback: what’s missing from your current test reports, and which HTTP client or framework should I support next?

Your test passed on retry. Your report should say so.

Harshad Lambate — Thu, 15 Oct 2026 15:28:16 +0000

Most Java test suites have a retry somewhere: an IRetryAnalyzer in TestNG, @RetryingTest from JUnit Pioneer, or Surefire’s rerunFailingTestsCount. Retries keep pipelines green. They also hide information.

When a test fails, gets retried and passes, most reports show one word: Passed. The failure that happened two minutes earlier, along with its stack trace, its API calls and the screenshot of what the browser showed, is gone. The test is flaky, and the report hides it.

The second problem is quieter. To get a useful report, teams end up writing reporting code inside their tests:

`java
test.log(Status.INFO, "Calling POST /users");
test.log(Status.INFO, "Response: " + response.asString());
Allure.addAttachment("Screenshot", new ByteArrayInputStream(png));`

That code isn’t testing anything. People forget to add it, it drifts out of date, and it lands in every test for the rest of the project’s life.

I built Ace Reports to fix both problems. Here’s what it does in Java.

One dependency, no reporting code
xml

`<dependency>
    <groupId>io.github.acereports</groupId>
    <artifactId>acereports-junit5</artifactId>  <!-- or acereports-testng / acereports-cucumber -->
    <version>1.1.0</version>
    <scope>test</scope>
</dependency>

There are no listeners to register, no base class and no annotations. Run mvn test as usual, and a single self-contained HTML file appears in TestResults/.

Every attempt keeps its own history

A test that fails and then passes on a retry is shown as flaky, with one tab per attempt. Each attempt keeps:

its own log lines,
its own error and stack trace,
its own API calls,
its own screenshots.

So when attempt 1 timed out and attempt 2 passed, you can see exactly what was different. Pass, fail, flaky and retried counts sit at the top of the report.

API calls are recorded automatically

This is a typical API test with no reporting code in it:

java

`java
class UsersApiTest {
private final HttpClient client = HttpClient.newHttpClient();

@Test
void createsUser() throws Exception {
    HttpResponse<String> response = client.send(
        HttpRequest.newBuilder(URI.create("https://reqres.in/api/users"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString("{\"name\":\"John\"}"))
            .build(),
        HttpResponse.BodyHandlers.ofString());
    assertEquals(201, response.statusCode());
}

}
`

The report’s API tab for this test shows the method, URL, request body, response body (JSON indented), status code and duration.

REST Assured calls are captured the same way, with no code.
Authorization and cookie headers are never stored.
One limitation: a client created inside the test method itself can’t be reached automatically, so you wrap it once with AceHttpClient.wrap(...).
Screenshots before teardown

The failure screenshot is taken before @AfterEach / @AfterMethod runs, so the browser is still open. Ace Reports finds a Playwright Page or Selenium WebDriver in a field of the test class, a base class or a ThreadLocal by itself. A page that never navigated anywhere (about:blank) is skipped, so a failed API test doesn’t get an empty screenshot.

Cucumber: steps are the log

With Cucumber (JUnit 5 or TestNG runner), each scenario is a row and every step is a line in the log:

gherkin GIVEN the login page is open WHEN I log in as "InvalidUser" with password "admin123" FAIL Step failed. TimeoutError: Timeout 3000ms exceeded. SKIPPED Then the dashboard is shown Scenario Outline rows carry their example values. Tags become categories. Images you attach with scenario.attach(...) show up as screenshot tabs. Writing to the report, when you want to

You never have to, but you can:

java

javascript Ace.info("Submitting payment"); Ace.takeScreenshot("After login");

Each line attaches to whichever test is running on the current thread, so parallel runs keep their logs apart.

Same report in .NET, Java and Python

Ace Reports started in .NET (xUnit, NUnit, MSTest, Reqnroll) and Python (pytest, pytest-bdd). The Java version produces the identical report, which helps when one team works across more than one stack.

Try it
Live demo report: **https://harshadlambate.github.io/AceReportsWebsite/demo.html
**Website and docs: https://harshadlambate.github.io/AceReportsWebsite/
Maven Central: https://central.sonatype.com/namespace/io.github.acereports

I’d like to hear how your team handles flaky tests: do you keep the history of each attempt, or only the final result?

I built a .NET test reporter to solve two problems I kept seeing in test automation

Harshad Lambate — Tue, 06 Oct 2026 16:04:00 +0000

I built Ace Reports — a .NET test reporter with automatic API capture and flaky-test detection

I've been working on test automation for several years, and one thing I kept finding frustrating was that a test report would tell me that a test failed, but not enough about what actually happened during the failure.

So I built Ace Reports around two problems I wanted to solve:

1. Identify flaky tests and preserve their history

If a test fails and then passes on a retry, I don't want the report to simply show the final Passed result. I want to know that the test was flaky, how many attempts it took, and what happened during those attempts.

2. Don't make testers add reporting code to their tests

I don't want testers to have to modify their test scripts just to populate the report. Things like API requests/responses, retry information, execution details, and screenshots on failure should be captured automatically wherever possible.

The goal is that you write your tests normally, run them, and the report automatically contains the information needed to investigate failures.

Ace Reports generates a self-contained HTML report, with no reporting server required. It currently has adapters for xUnit, NUnit, MSTest, and Reqnroll.

The project is available on NuGet and is currently at v1.0.1.

I'd like to get feedback from people working with .NET test automation:

What information do you wish your test reports captured automatically that they currently don't?

I'm especially interested in feedback around API capture, flaky-test detection, retries, and report usability.

Website: https://harshadlambate.github.io/AceReportsWebsite/