Data seeding / fixtures for NetSuite automated testing

62 Views Asked by At

We have Selenium tests covering scenarios for our NetSuite (rel. 2023.1) customizations, but struggling with repetitiveness of the tests, since some operations cannot be "undone" (as per accounting/business logic). This IMHO clearly calls for data seeding/fixtures so each test suite starts "afresh"... What are the best practices and options to seed data into NetSuite Sandbox instance? (Not copying from PROD instance - that seems to fragile).

1

There are 1 best solutions below

0
On

In your test teardown a great many things can be 'undone' but the major problem is managing external side effects. (e.g. system generated emails, user events and workflows that trigger calls to external APIs).

I have used a couple of different strategies and none are without issues. The approach is pretty general but the implementations are anything but.

  1. if your tests work on existing records then create test records in your test setup.

  2. Flag any records created with a custom checkbox field and then post test delete all those.

  3. if your tests create records then flag them as test records as part of the creation.

Issues

  • The test flags have to go all the way down. You may have to modify non-related scripts and workflows to not run on your test records.
  • clean up has to go all the way down. e.g. if you create or modify transactions you need to have cleanup scripts that delete all of the created records. First creating a tree of the transactions and then deleting from outer most and working in.
  • side effects must be managed. Not so bad for a sandbox account but I've had to work in situations where the customer had no sandbox and such things like automated customer emails can be a nightmare. This is mitigated by creating test customers but again that can be a lot to do in your setup/teardown scripts
  • If you are creating a suiteapp then features and configuration are interesting since every Netsuite account can have a different mix of configurations, settings, apps, workflows and scripts. Add international versions and reliable automated testing begins to feel impossible. Not to say not worth doing because it absolutely is but in the wild you will find your tests were not adequate and you won't have a clear path to incorporating a customer's troublesome account in your dev account based testing.