0

My application requires my users to go through a series of forms so that I can collect data and eventually action all the data from the series of forms at the end (picture an insurance application or something similar). There are requirements that exist all along the way that aren't easily unit-tested, and I'm wondering what good practices I can employ to test my API to keep my test suite DRY and to facilitate as easy a process as possible for test-writing going forward.

As an example of a requirement that I would test: A user enters some personal metadata about themselves in one stage of the application (address, dob, etc.). The user has a dashboard they can always visit to see a basic overview of their account. I need to make sure that while in the process of filling out the application form, they can move to their dashboard and see the values surfaced.

What are some testing patterns that I can employ to be DRY? I think that if I were to just isolate every feature test and re-write the entire test setup to get a user to the stage of filling out an application, things would be simple, but that's certainly going to slow down the testing process.

lyonssp
  • 117
  • 1
  • 1
  • 7
  • Do you have to test through the UI or can you set up the data to get to the thing you actually want to test? I.e. what is the result of filling the metadata? Is this sent/stored/retrieved somewhere? Can you insert in it a database or retrieve it from a service? If the latter, can you mock that service so you can set up your test cases with the (mock) data needed for that test case? – Marit Feb 04 '18 at 05:44

1 Answers1

0

There are three common patterns that you may want to consider:

The first provides a tester-friendly interface on top of the underlying application architecture.

AddressForm addr = application.newAddress();
addr->enterStreet("My Street");
...
Dashboard dashboard = application.dashboard();
test.compare(dashboard.street(), "My Street");

Data-driven testing can be on top for easily going through various combinations based on a CSV file for example.

Model-driven may be an option if you have an architecture of your application ready that describes possible states and transactions. The various possible paths of the model can be visited automatically thus avoiding the need to script all possible combinations manually.

Harri
  • 364
  • 1
  • 5
  • You might also want to look into Screen Play Pattern. Although, it might be better (faster, less brittle) if you don't have to go through the UI at all. – Marit Feb 04 '18 at 05:45