How do I create front end test data based on backend model's schema?

Question

I'm really struggling with creating robust tests for my frontend because of the coupling in data schema between my backend and frontend.

To clarify, I have a Django rest API and I have a front end that queries serialized forms of my Django API backend models. When I want to generate test data for my backend, I use a factory (factory_boy library) to easily create model instance I can test on.

In my front end, the data passed around is assumed to have the same structure as the backend models. Whenever I change something in my backend models, I have to change my front end to fit the new structure. So how do I create robust front end test data if changing my backend models means I have to rewrite all my test data?

Should I replicate the factory pattern I have in the backend? Is there a best practice to avoid having to maintain two factory replicas?

I've considered a possible solution but that would likely involve a lot of extra work unless there's a library out there that does this already: Create endpoints in my backend that return output from my model factories and that can be accept json data to overwrite the defaults on the factory. My front end can then call these to generate test data during test set up.

Answer 1

You could write a test data generation package that parsed the schema and for each valid data structure generated a set of test data based on the permitted values for the types within that data plus invalid values based on a set of rules.

Typical rules would include:

• Range limited integer: test at:
  • range min,
  • range max,
  • 0 if in range and not already there,
  • a couple of random values within the range
  • plus, (if possible to do so),
  • range min -1,
  • range max +1,
  • type min representable &
  • type max representable.
• String
  • A selection of expected strings
  • Zero length string ""
  • All nulls string
  • Max length
  • Max length +1
  • All the valid characters
  • Some invalid or unexpected characters
• Enum or Choice
  • Every valid value
  • Last value + 1
  • Max store-able value (depending on your storage type this will probably be 0xffff or 0x7fff)
  • If enums are signed then -1 & MAX NEG

Of course an old favourite is to also deliberately test with the previous couple of iterations of valid data structures to make sure that the code handles out of sync results gracefully, i.e. what happens if the back end is reverted or the front end connected to an out of date installation.