ERPNext Testing

Hari Mahesh

ERPNext testing helps retailers, distributors, and store operators verify that critical business workflows function as expected. ERPNext is an open-source business management platform that connects sales, purchasing, inventory, accounting, and manufacturing. A sale can flow into invoicing and payment, while stock movements and purchasing keep the business running behind the scenes.

It also means a small problem can affect more than one team. A sales order may save successfully but produce the wrong invoice total. A delivery may appear complete while the stock ledger records the wrong quantity. A payment may be submitted without changing the customer’s outstanding balance. ERPNext testing should confirm that these connected workflows behave as staff expect, not merely that individual screens open.

This guide shows how to test the operations behind an ERPNext-powered store with testRigor, using a real set of ten browser tests covering sales, payments, stock, purchasing, manufacturing, and accounting. If you also operate a public online storefront, its product pages, cart, and checkout require additional tests; the example suite here focuses on the ERPNext management interface.

A practical ERPNext testing strategy combines unit testing, integration testing, and end-to-end testing. Each layer addresses a different kind of risk.

What Should ERPNext Testing Cover?

• Sales orders and invoices: Make sure an order creates an invoice with the expected customer, item, tax, and total.
• Delivery and inventory: Confirm that shipping an item produces the correct stock movement.
• Customer payments: Check that recording a payment updates an invoice from Unpaid to Paid.
• Customers and item pricing: Ensure new customer and product records are usable in later transactions.
• Purchasing and replenishment: Follow purchase orders through receipt and supplier invoicing.
• Warehouse transfers: Check quantities, amounts, and source and destination warehouses.
• Manufacturing: Verify bills of materials, work orders, material transfers, and finished goods.
• Accounting: Confirm that journal entries are balanced and appear in the ledger.

These scenarios are especially valuable because each connects multiple ERPNext documents. A successful Save action is not enough: the next document, report, or status must reflect the transaction correctly.

What ERPNext Already Checks, and What It Does Not

ERPNext has its own automated testing infrastructure. Its official repository includes application-level tests, such as Sales Order tests, along with CI workflows for server testing. These checks are important for developers changing the platform’s business logic.

However, they do not establish that every company’s configured ERPNext site works end to end. Your tax templates, price lists, warehouses, permissions, custom fields, installed applications, and operating procedures may differ from the development environment.

The example ERPNext contribution used in this article adds ten plain-English browser tests and six reusable rules, rather than changing ERPNext application behavior. It illustrates how to validate the results visible to employees after they perform real business actions.

Unit Testing in ERPNext

Unit tests check a small part of application logic in isolation. For example, developers can validate calculations, validation rules, or state transitions without navigating through an entire transaction in a browser.

These tests are useful when maintaining ERPNext or creating customizations. Yet a passing unit test cannot tell a store manager whether an employee can select an item, submit an order, and see the right invoice total in the configured site.

Integration Testing in ERPNext

Integration testing checks how components exchange information. In ERPNext, important boundaries include sales documents and accounting entries, deliveries and inventory, purchase receipts and supplier invoices, and work orders and stock movements.

For example, creating a Sales Invoice should produce the appropriate receivable and tax effects, while a submitted Delivery Note should update stock. Integration tests can verify those relationships at the application level. End-to-end tests add one more question: can a person complete the entire process through the interface?

End-to-End ERPNext Testing

End-to-end (E2E) testing follows complete user journeys through the application. A sales workflow might look like this:

Choose a customer → create a Sales Order → submit it → create a Sales Invoice → verify the total and invoice status.

Another journey follows a payment:

Create an invoice → record payment → submit the Payment Entry → return to the invoice → confirm that it is Paid.

These workflows test much more than navigation. They check whether values, documents, and statuses remain consistent as the transaction moves between modules.

You can automate ERPNext browser testing with tools including testRigor, Selenium, and Playwright.

testRigor

testRigor lets teams write end-to-end tests using plain-English commands based on visible text and user actions. This makes it approachable for QA specialists and business users who understand ERPNext processes but do not want to maintain a traditional browser automation framework.

For example, a test can express an outcome as check that page contains "Unpaid" or check that page contains "$ 42.40". Reusable Rules can group recurring actions such as logging in or opening the Selling module.

ERPNext’s interface also has dynamic grids, autocomplete fields, and action labels that sometimes require extra care. The reliability tips below explain techniques used in the actual example tests.

Selenium

Selenium is an established browser automation framework with language bindings and extensive control over browser interactions. It is suitable for teams comfortable writing and maintaining automation code. ERPNext interface updates may require the team to revisit locators and synchronization logic.

Playwright

Playwright provides browser automation APIs, assertions, and tooling for code-driven tests. It can be a strong fit for development teams that already use JavaScript, TypeScript, Python, or other supported languages. The trade-off is that tests still need code ownership and upkeep.

ERPNext Testing with testRigor: How to Perform End-to-End Tests

Let’s build a practical test that checks whether a store employee can turn a customer order into an invoice. The walkthrough is based on the example test files in tests/E2E, not on an invented demo workflow.

Create Your ERPNext Test Suite

Step 1: Sign in to testRigor or create an account.

Step 2: Create a new test suite with a recognizable name such as ERPNext Store Operations Regression.

Step 3: Choose Desktop Web Testing and provide your ERPNext staging URL. Select the operating system and browser you want to check.

Step 4: Configure suitable testing credentials or keep them in secure test data. Use English for the example suite because its verified commands depend on English labels.

Step 5: Select the option to create your own test cases, then add a custom test case for the sales-order workflow.

Your store’s URL, field labels, permissions, and configuration may differ from this example. Validate the test against your own staging instance before using it as a regression check.

Set Up a Safe ERPNext Test Environment

These tests create and submit financial and inventory documents. Run them against a disposable or staging ERPNext site, not the live business database. A realistic environment should reproduce the modules, installed applications, role permissions, currency, tax settings, and warehouses that matter to your business.

The example suite’s setup instructions use a seeded company and known records. The values below explain the example; they are not universal ERPNext defaults.

Keep credentials outside the test steps. The example uses the stored values erpnextUser and erpnextPassword. For records the test creates, use generated names so repeated executions do not collide with earlier data. Reset stock and accounting data between full test cycles when possible.

Test Case: Create a Sales Order and Confirm the Invoice

This case verifies a high-value business outcome: an employee can record an order and produce an invoice with the correct amount. In the seeded environment, a $40.00 item plus 6% sales tax should leave $42.40 outstanding on an unpaid invoice.

Step 1: Log In and Open Selling

The suite starts from the ERPNext login page. The two first lines below are existing Reusable Rules in the supplied contribution.

log in as administrator
open the selling module
click "Sales Order"
click "Add Sales Order" using OCR only

The using OCR only modifier is intentional. In the tested ERPNext interface, the visible text of some page-action buttons is split by a keyboard-shortcut underline, so a standard text match does not reliably identify the whole label.

Step 2: Select the Customer and Delivery Date

Choose the seeded customer and a fixed future delivery date. The example closes the date picker after entering the value so it does not cover other controls.

enter "E2E Seed Customer A" into "Customer"
press Tab
enter "2030-01-31" into "Delivery Date"
press Escape

Step 3: Add the Item and Verify Its Selling Rate

ERPNext uses an editable item grid. The test selects a product from the autocomplete list and checks the rate that appears, rather than assuming the field was populated correctly.

click on table at row "1" and column "Item Code"
type "E2E-SEED-002"
check that page contains "E2E-SEED-002, Products"
press Enter
check that page contains "$ 40.00"

Step 4: Save and Submit the Sales Order

ERPNext distinguishes a saved draft from a submitted business document. Verify both stages before moving to invoicing.

click "Save" using OCR only
check that page contains "Draft"
click "Submit" using OCR only
click "Yes"
check that page contains "To Deliver and Bill"

Step 5: Create the Invoice and Verify the Total

The next action creates a Sales Invoice from the submitted order. The sample test checks the resulting status and outstanding amount, not merely the confirmation dialog.

click "Create"
click "ales Invoice"
click "Save" using OCR only
click "Submit" using OCR only
click "Yes"
check that page contains "Unpaid"
scroll down until page contains "Outstanding Amount"
check that page contains "$ 42.40"

The shortened ales Invoice string is taken from the verified test script. It targets the remaining text of a Create-menu entry whose shortcut letter is rendered separately. It is specific to the tested interface, not a recommended replacement for every ERPNext installation.

Complete Test Case

After creating the two reusable rules, the complete case remains short and readable. This is the exact example’s step sequence, with no additional unverified commands.

log in as administrator
open the selling module
click "Sales Order"
click "Add Sales Order" using OCR only
enter "E2E Seed Customer A" into "Customer"
press Tab
enter "2030-01-31" into "Delivery Date"
press Escape
click on table at row "1" and column "Item Code"
type "E2E-SEED-002"
check that page contains "E2E-SEED-002, Products"
press Enter
check that page contains "$ 40.00"
click "Save" using OCR only
check that page contains "Draft"
click "Submit" using OCR only
click "Yes"
check that page contains "To Deliver and Bill"
click "Create"
click "ales Invoice"
click "Save" using OCR only
click "Submit" using OCR only
click "Yes"
check that page contains "Unpaid"
scroll down until page contains "Outstanding Amount"
check that page contains "$ 42.40"

Execution Results

After running the case, use testRigor’s execution details to review whether it passed, the step at which it stopped, screenshots, and associated execution information. A failing business assertion—such as an incorrect outstanding amount—deserves investigation even when the document was submitted successfully.

The ERPNext public testRigor suite provides the example suite link. The source-controlled implementation also documents ten test cases and a successful GitHub Actions run from November 4, 2026; its README reports a 10/10 pass for that run. That historical result is not a guarantee about your own ERPNext site or future executions.

You can view the complete test execution, including results and screenshots, in the public ERPNext testRigor execution.

Useful testRigor Capabilities

• Reusable Rules: Share login and module-navigation sequences across test cases.
• Stored test data: Keep environment credentials and repeatable values separate from the main steps.
• Text-based assertions: Check amounts, transaction statuses, and visible document information.
• Table interaction: Work with ERPNext’s document grids using their rows and columns.
• OCR-assisted interaction: Handle interface labels whose rendered structure prevents a standard text match.
• CLI and CI integration: Run the same source-controlled suite in a local or temporary environment when a technical team needs that workflow.

Additional Resources

• testRigor language documentation
• testRigor CLI documentation
• End-to-end testing guide
• ERPNext Sales Order documentation

High-Value ERPNext Testing Scenarios

The sales-order walkthrough is only one part of store operations. The example repository includes nine more browser cases. The following scenarios show what they validate and what your own regression suite could protect.

1. Verify Customer Records and Item Pricing

A new customer must be available when staff create an order. The sample customer test generates a unique name, saves the quick-entry form, reopens the Customer list, and checks that the record appears. That last check matters because the list does not always refresh immediately after quick entry.

For pricing, the suite creates an item with a unique code and a Standard Selling Rate of $12.50. It then opens a Sales Order and verifies that selecting the new item retrieves that rate. This catches a configuration failure that a simple “Item saved” message would miss.

2. Verify Delivery Notes and the Stock Ledger

For physical goods, confirming an order does not mean inventory has left the warehouse. The example submits a Sales Order for E2E-SEED-001, creates a Delivery Note, and opens View → Stock Ledger.

check that page contains "Out Qty"
check that page contains "-1.000"
check that page contains "Stores - ETC"

A useful extension is to confirm that the ledger entry belongs to the delivery created by that particular test run. Checking only a warehouse’s overall balance can produce misleading results when other tests also move stock.

3. Verify Customer Payments and Invoice Status

Once an invoice exists, record a payment and return to that invoice. The example creates a $42.40 Sales Invoice, checks that the Payment Entry carries the amount, submits it, and confirms that the original invoice changes to Paid.

check that input "Paid Amount (USD)" has value "42.40"
click "Save" using OCR only
click "Submit" using OCR only
click "Yes"
check that page contains "Submitted"
go back
check that page contains "Paid"
check that page does not contain "Unpaid"

Checking the original invoice is the important final assertion: it shows that accounting information has propagated back to the business document.

4. Verify Purchasing and Replenishment

A store cannot fulfill orders reliably without dependable purchasing. One example test follows a Purchase Order through a Purchase Receipt and Purchase Invoice. It confirms the expected statuses and a sample outstanding amount of $21.20 for a $20.00 item under the seeded 6% tax setup.

Another begins with a Material Request for E2E-SEED-003, creates a Purchase Order, checks the $84.80 grand total, and verifies that the request changes to Ordered. These checks connect purchasing decisions to the documents that complete them.

5. Verify Stock Transfers Between Warehouses

Inventory transfers are an excellent place to test calculated values before submission. The example moves two units of E2E-SEED-002 from Stores – ETC to Work In Progress – ETC and verifies that the row’s Basic Amount and the document’s Total Outgoing Value are both $80.00.

click on table at row "1" and column "No."
check that page contains "Editing Row"
check that page contains "$ 80.00"
press Escape

After submission, the case also checks the Stock Ledger for the outgoing quantity and both warehouses. The early amount assertion is important: it can expose a missing browser-side recalculation that saving the document might otherwise conceal.

6. Verify BOMs, Work Orders, and Finished Goods

For stores that assemble or manufacture products, a sale may depend on a longer sequence. The example creates a Bill of Materials (BOM), generates a Work Order, transfers materials, records manufacturing, and checks that the Work Order reaches Completed.

The test also verifies the Work-in-Progress Warehouse value before production begins. This is a regression-sensitive part of the workflow because an incorrect warehouse default can disrupt material movement even if the work order itself can be saved.

7. Verify Balanced Journal Entries

Not every accounting task starts from a sale. The example opens the Journal Entry Quick Entry form, records a $150.00 debit to Miscellaneous Expenses – ETC and a corresponding credit to Cash – ETC, then submits the entry.

The final check opens the General Ledger and confirms both accounts and the amount. This validates the accounting result rather than stopping after the draft document is created.

Reusable Rules for ERPNext Testing

When several cases begin with the same login and module navigation, repeating every action makes a suite harder to maintain. The example contribution stores six Reusable Rules: one for administrator login and one each for the Selling, Buying, Stock, Manufacturing, and Accounts modules.

enter stored value "erpnextUser" into "Email"
enter stored value "erpnextPassword" into "Password"
click "Continue"
check that page contains "ERPNext"

click "ERPNext"
click "Selling"
check that page contains "Sales Order"

A test can then call those rules by name instead of copying their internal steps. If navigation changes after an ERPNext update, the team can adjust the shared rule in one place.

ERPNext Testing Tips for Reliable Automation

• Check what the interface displays, not just what was saved. A transaction can be submitted while a downstream total, status, or ledger result is still wrong.
• Handle keyboard-shortcut labels carefully. Some action buttons split their visible text around an underlined shortcut letter. In the example, using OCR only works for page actions such as Save and Submit.
• Wait for autocomplete options before selecting them. Item and warehouse link fields may update after typing. The tested grid selects an option with Enter once the expected value is visible.
• Commit edited grid cells deliberately. Leaving the last column with Tab can add an unwanted empty row. The stock transfer example clicks another cell to commit the quantity before saving.
• Watch for overlapping date pickers. Changing Supplier or Delivery Date fields can leave a calendar covering the next field. Closing it avoids entering data into the wrong control.
• Distinguish current status from the document timeline. An older status such as Pending or To Bill can remain in the activity history after the current document becomes Ordered or Completed.
• Use isolated data for repeatable runs. Submitted Delivery Notes and Stock Entries consume or move real quantities within the test database. Reset or reseed the staging environment before accumulated transactions interfere with later runs.
• Account for hidden previously visited forms. In the tested interface, a prior form could remain hidden in the page structure. Reloading before the next grid-based form resolved an ambiguous table interaction.

These are observations from the example implementation, not assumptions about every ERPNext version or customization. Use them when you encounter the same behavior in your environment.

When to Run Your ERPNext Testing Suite

Automated regression tests are most useful when they run around changes that can affect the business. Prioritize execution after ERPNext upgrades, app or customization changes, tax and price-list updates, warehouse configuration changes, payment integration changes, and before an important sales or replenishment period.

For a practical starting point, run a small daily smoke suite for login, customer creation, invoicing, and payment status. Run the longer purchasing, warehouse-transfer, manufacturing, and accounting suite after significant changes or on a planned schedule. Your frequency should reflect the value and side effects of each workflow.

ERPNext Testing for Development Teams: Git, Docker, and CI/CD

Git, Docker, and CI/CD are optional for teams that create and run cases directly in testRigor. They are useful when developers or implementation partners want to keep test files beside their customizations and run the tests against a temporary ERPNext installation.

The example commit includes the following source-controlled layout:

Running ERPNext Tests with the testRigor CLI

For the specific checked-in example, the README calls for Node.js 24 and testRigor CLI version 2.0.9. It expects an ERPNext site containing the example data. The commands below are for a technical test environment, not a production store.

npm install -g @testrigor/[email protected]

testrigor test-suite run "$TESTRIGOR_SUITE_ID" \
  --auth-token "$TESTRIGOR_AUTH_TOKEN" \
  --localhost --url http://localhost:8080 \
  --explicit-mutations \
  --test-cases-path 'tests/E2E/test-cases/*.yaml' \
  --rules-path 'tests/E2E/rules/*.txt' \
  --variables-path tests/E2E/variables.json

The --localhost option lets testRigor’s browsers reach a locally running ERPNext site. The --explicit-mutations option allows local files to update the remote suite, so use it only with a dedicated suite that you intend to synchronize. For a different environment, supply your own secure variables and seed data.

Setting Up GitHub Actions

The included workflow uses a disposable ERPNext stack and a localhost tunnel. It is scheduled nightly and can be run manually from GitHub Actions. It does not run on pull requests; that avoids relying on secrets unavailable to forked pull-request workflows.

To enable it, configure TESTRIGOR_AUTH_TOKEN as an Actions secret and TESTRIGOR_SUITE_ID as an Actions variable. The workflow first checks whether both values exist; otherwise it skips the E2E job. Successful technical runs can upload a JUnit report, and the script saves logs for troubleshooting.

This arrangement is useful for teams managing ERPNext code, but store managers do not need it to benefit from the same tests. A staging environment and a testRigor suite are enough to begin checking the business journeys described above.

What About Testing an ERPNext Online Storefront?

ERPNext is an ERP platform, not just a shopping-cart application. Businesses using its online commerce features may also have a separate customer-facing shopping experience. According to ERPNext’s e-commerce documentation, the Webshop app is required for e-commerce features in version 15.

If you operate that storefront, add a separate end-to-end test that follows the shopper from product discovery through cart and checkout, and then validates the resulting records in ERPNext. Also consider price and availability visibility, customer registration, payment sandbox behavior, and the handling of out-of-stock items. These are recommended extensions, not scenarios demonstrated by the ten-test suite in this article.

Conclusion

A store can look operational while an important transaction fails farther down the workflow. A Sales Order may not produce the expected invoice, a payment may not settle the balance, or a warehouse transfer may record the wrong amount. ERPNext testing should protect the complete process, from the action an employee performs to the document, status, or ledger entry the business relies on.

Unit and integration tests validate application logic and interactions between components. End-to-end tests complement these layers by verifying that critical business workflows function as expected through the ERPNext interface.

Start with a small set of high-value scenarios covering sales, invoicing, payments, and inventory. As your testing strategy evolves, expand coverage to purchasing, manufacturing, accounting, and, where applicable, customer-facing storefront checkout.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT