Set up an automated testing tool to check a software project repeatedly and report failures without relying on manual checks. This guide is for developers who can run a project and use its command line, but have not yet connected its tests to an automated workflow. You will choose a tool that fits the project, add one useful test, run it on your machine, and configure it to run in continuous integration. Allow 1–3 hours; the time depends on the project and CI provider.
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Hands-On Automated Testing with Playwright: Create Fast, Reliable, and Scalable Tests for Modern Web Apps with Microsoft’s Automa…
- ✔ Format: Book
- ✔ Topic: Automated testing with Playwright
- ✔ Framework: Microsoft Playwright
Software Testing with Selenium: Automated Testing Tool Book for Beginners
- ✔ Format: Book
- ✔ Topic: Selenium automated testing
- ✔ Level: Beginner
Automated Testing Unleashed: Automated Testing Engineering Fundamentals — The Complete Handbook, Volume 1
- ✔ Format: Book
- ✔ Topic: Automated testing engineering fundamentals
- ✔ Series: Automated Testing Unleashed: The Complete Handbook
Difficulty: Intermediate | Time: 1–3 hours
What You’ll Need
Tools & Materials:
- A software project with a working local development environment
- The project’s package manager or build tool
- A code editor and terminal
- Access to the project’s CI service, such as GitHub Actions, GitLab CI, or another provider
Knowledge:
- How to start the application or run its existing build command
- Basic command-line use and editing project files
- The expected behavior of the function, module, or user flow you plan to test
Choose a small, stable behavior for the first test. If the project already has a test framework or CI workflow, inspect those files first and extend the existing setup rather than adding a second tool. Keep credentials, production data, and private configuration out of test files.
Hands-On Automated Testing with Playwright: Create Fast, Reliable, and Scalable Tests for Modern Web Apps with Microsoft’s Automa…
This is the most direct match for readers who want to create automated browser tests for a web application. Its stated focus on Microsoft Playwright and hands-on test building gives it a practical edge over the more introductory Selenium title and the wider fundamentals scope of Automated Testing Unleashed. The promise of fast, reliable, and scalable tests also points toward concerns that matter as a test suite grows: whether tests remain useful and manageable as an application changes.That specific focus is also the main limitation. Readers looking for a broad introduction to test engineering may find the scope narrower than the handbook, and Selenium learners will need a different resource for that framework. Playwright evolves, so a book can age as APIs and recommended practices change. The supplied information does not identify edition details or chapter-level coverage, so we cannot confirm how current or comprehensive its examples are. Still, among these three books, it provides the clearest route from learning to writing web automation.
Pros:
- Centers on a modern browser automation framework
- Promises a hands-on approach to web testing
- Addresses reliability and scalability as well as test creation
- Has the clearest practical web automation focus in this comparison
Cons:
- Framework-specific coverage may not transfer directly to Selenium projects
- Playwright changes over time, which can date examples
- Available details do not confirm edition freshness or chapter depth
Best for: Developers and QA practitioners who want a practical introduction to automating tests for modern web apps with Playwright.
Not ideal for: Readers who need framework-neutral testing principles, Selenium instruction, or confirmed coverage of a particular Playwright release.
Bottom line: We rank this first for its stated practical Playwright focus, while recommending that buyers verify the edition and contents before relying on it for current implementation details.
“We rank this first for its stated practical Playwright focus, while recommending that buyers verify the edition and contents before relying on it for current implementation details.”
Software Testing with Selenium: Automated Testing Tool Book for Beginners
If we are new to browser automation and already expect to work with Selenium, this title makes its intended audience unusually clear: beginners learning Selenium. That makes it a more targeted first step than the Playwright book for readers on Selenium-based projects. Compared with Automated Testing Unleashed, it also names a concrete tool, which can make the learning goal easier to define.The tradeoff is how little is known about the material. The description says it teaches fundamentals, but does not establish whether it includes guided exercises, project examples, setup help, or advice for debugging flaky tests. The Playwright book makes a stronger stated promise around practical and scalable test creation, while the handbook signals broader engineering coverage. This book may suit a reader who simply needs a Selenium-oriented entry point, but buyers seeking evidence of depth or a complete curriculum should inspect the table of contents before committing. Its beginner framing is a useful signal; it is not proof of how accessible or comprehensive each lesson is.
Pros:
- Clearly identifies Selenium as its subject
- Explicitly targets beginners
- Provides a focused alternative to the Playwright-specific guide
- Can help readers align a learning resource with a Selenium project
Cons:
- Available description gives limited detail about the content
- No stated information confirms exercises or project-based instruction
- Does not indicate coverage of broader test engineering practices
Best for: Readers starting with automated web testing who specifically need a beginner-oriented introduction to Selenium.
Not ideal for: Experienced automation engineers, Playwright learners, or buyers who need a verified syllabus and detailed examples before selecting a book.
Bottom line: We place this second as the most explicitly beginner-oriented choice for Selenium, with the caveat that its instructional depth is difficult to judge from the available details.
“We place this second as the most explicitly beginner-oriented choice for Selenium, with the caveat that its instructional depth is difficult to judge from the available details.”
Automated Testing Unleashed: Automated Testing Engineering Fundamentals — The Complete Handbook, Volume 1
This handbook is the broadest option in the group. Its stated subject is automated testing engineering fundamentals, rather than instruction in a named browser framework. That makes it a plausible choice for readers who want to think about test automation as an engineering practice before narrowing in on Playwright or Selenium. The volume-one designation and handbook series may also appeal to learners looking for a structured path beyond a single title.For someone choosing a tool to use immediately, though, this breadth makes the book less direct than the Playwright guide or the Selenium introduction. The supplied description does not name specific frameworks, practical exercises, or the precise topics covered, so we cannot tell how readily the fundamentals translate into day-to-day test writing. It may complement either tool-focused book, but the available information does not establish that it teaches either framework. We rank it third in a roundup of automated testing tools because its strongest stated value is foundational learning, not selecting or mastering a particular automation tool.
Pros:
- Focuses on automated testing engineering fundamentals
- Offers a wider stated scope than either framework-specific title
- Is presented as the first volume in a handbook series
- May pair with later framework-specific learning
Cons:
- Available details do not verify the handbook’s depth or structure
- No specific automation framework is identified
- Its broad scope is less direct for readers seeking browser test examples now
Best for: Readers who want a general grounding in test automation engineering and may continue through a multi-volume handbook.
Not ideal for: People who need immediate, framework-specific instruction in Playwright or Selenium or want confirmed details about exercises and coverage.
Bottom line: We recommend it for readers prioritizing general automation principles, but choose one of the other titles when learning a particular web testing framework is the immediate goal.
“We recommend it for readers prioritizing general automation principles, but choose one of the other titles when learning a particular web testing framework is the immediate goal.”
As an Amazon Associate we earn from qualifying purchases.
Before You Start
Automated testing tools serve different purposes. Unit test frameworks check small pieces of code, integration tests check how components work together, and browser automation tools exercise a user interface. Begin with the smallest test that gives useful feedback. Confirm that the project builds or runs before changing its test setup; otherwise, existing failures may be mistaken for setup problems. Make a branch or commit your current work so you can review the changes.
Step-by-Step Instructions
Step 1: Identify the test you need
Write down one behavior as a clear input and expected result. For example: “When the quantity is zero, the price calculator returns zero,” or “Submitting the sign-in form with valid details opens the account page.” Pick a behavior that can be checked repeatedly without depending on unpredictable external services.
Tip: Avoid starting with a test that requires production credentials, live payment services, or real customer data. Use a documented test fixture or a local substitute where needed.
Check: You can describe the test’s starting conditions and expected result in one or two sentences.
Step 2: Inspect the project’s existing setup
Open the project’s dependency manifest, build configuration, test folders, and CI workflow files. Look for existing test commands and dependencies. Run the documented test command, if one exists, and note any failures before editing files.
Tip: Common places include package scripts and lockfiles in JavaScript projects, test configuration files in Python projects, and build files in Java or .NET projects. Follow the project’s own conventions.
Check: You know whether a test framework is already installed, how tests are started, and whether the current project passes its existing checks.
Step 3: Choose a compatible testing tool
Select a tool that supports the project’s language, runtime, and test type. Prefer the framework already used by the repository. If none exists, check the tool’s official installation instructions and verify that its supported runtime matches the project’s version. For browser tests, choose a browser automation tool only if the test needs to exercise a real browser.
Tip: Do not pick a tool solely because it is popular. A tool that fits the project’s current build and CI environment is easier to maintain.
Check: You can name the tool, the kind of test it will run, and the project version it supports.
Step 4: Install the tool and add a test command
Install the testing dependency using the project’s package manager or build tool, following its official instructions. Save it in the appropriate development or test dependency group. Add a clear command, such as test, to the project’s existing scripts or build configuration. Use the lockfile and commit it with the dependency changes.
Tip: Use the same package manager that the repository already uses. Mixing package managers can create conflicting lockfiles and different dependency versions across machines.
Check: The dependency appears in the project configuration, and the new test command starts the test runner instead of returning a command-not-found error.
Step 5: Write one focused test
Create a test file in the location and naming style used by the project. Set up the input, call the code or flow being tested, and assert the expected result. Keep the test focused on one behavior so a failure points to a specific problem. Use stable test data and reset any state the test changes.
Tip: A test should fail when the behavior is wrong and pass when it is correct. Avoid assertions that only confirm the test ran, such as checking that a value exists when the expected value is known.
Check: The test runner discovers the test, displays its name, and reports a pass when the expected behavior is present.
Step 6: Run the test locally and check its failure signal
Run the new test command from the project root. Read the output, correct setup or assertion errors, and run it again. Temporarily change the expected result or use a known invalid input to confirm that the test fails, then restore the correct assertion and rerun it.
Tip: Restore the test immediately after checking its failure behavior. Do not commit the intentionally failing version.
Check: The test passes with the correct code and produces a clear failure when the behavior does not match the assertion.
Step 7: Add the test command to continuous integration
Open the existing CI workflow and add the test command after the project’s runtime and dependencies are installed. Use the project’s documented runtime version and install dependencies from the lockfile where possible. Keep the test step’s output visible in the CI log, and avoid printing secrets.
Tip: If no workflow exists, use the CI provider’s official starter configuration for the project’s language and package manager. Keep the first workflow small: install, run the relevant checks, and report the result.
Check: The workflow configuration includes a step that runs the same test command you used locally.
Step 8: Run the workflow and review the result
Commit the test and workflow changes, then push the branch or open a change request to trigger CI. Open the run details and inspect the test step, not just the overall status. If it fails, use the log to identify whether the issue is dependency installation, runtime configuration, environment variables, or the test itself.
Tip: A green workflow is useful only if it actually ran the test step. Check that the step was not skipped by a condition or limited to a different branch or event.
Check: The CI run shows the test command executing and passing, with a visible result tied to the commit you pushed.
Common Mistakes to Avoid
- Installing a second test framework when the project already has one. — Inspect dependencies, scripts, configuration, and existing test files before selecting or installing a tool.
- Writing a test that depends on live services or changing data. — Use fixed inputs, isolated fixtures, and local substitutes so repeated runs produce the same result.
- Adding a CI test step without matching the local runtime or dependency install. — Use the project’s specified runtime and lockfile-based installation in both environments.
- Treating a green CI run as proof when the test step did not run. — Open the workflow log and confirm the test command executed for the commit under review.
Troubleshooting
Problem: The test command is not found.
Solution:
Confirm that the dependency installation completed and that you are running the command from the project root. Check the manifest for the exact script name, then install dependencies with the project’s chosen package manager.
Problem: The test passes locally but fails in CI.
Solution:
Compare the runtime versions, dependency install commands, working directory, and required environment variables. Remove reliance on files or services that exist only on your machine, then rerun the workflow.
Problem: The test runner reports that it found no tests.
Solution:
Check the runner’s file naming and folder conventions. Confirm the test file is included by the configuration and that the CI command points to the correct project directory.
Problem: The test gives different results on repeated runs.
Solution:
Look for shared state, random values, dates, network calls, or tests that run in parallel and modify the same resource. Replace unstable inputs with fixed values and reset state before each run.
What Success Looks Like
The project has a documented test command, at least one focused test with a meaningful assertion, and a CI workflow that runs that command. The test passes locally and in CI, its output identifies the test and result, and a deliberate mismatch causes a clear failure. A later change that breaks the tested behavior should make the check fail.
Next Steps
Add tests for other high-value behaviors, especially cases that have caused defects or support requests. Keep each test isolated and readable. Review failures when code changes, remove obsolete tests when behavior changes, and update the CI runtime or dependencies when the project’s supported versions change. For slower browser or end-to-end tests, consider running a smaller fast suite on every change and a broader suite on a schedule or before release.
Frequently Asked Questions
Which automated testing tool should I use?
Use the framework already established in the project when possible. Otherwise, choose one that supports the project’s language and runtime and matches the test type: unit, integration, or browser-based.
Do I need to test every line of code?
No. Start with behaviors that matter to users or carry a higher risk of failure. A small set of clear tests is more useful than many tests that do not check meaningful outcomes.
Should tests run on every commit?
Run a fast, reliable test suite on every change through CI. Longer suites can run before releases or on a schedule if running them on every change would slow the team substantially.
What should I do when a test fails?
Read the failing test name and assertion, then compare the actual result with the expected result. Decide whether the code is broken, the test data is unstable, or the expected behavior has changed. Update the test only when the intended behavior has changed.
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
