1

I'm a front-end developer, working on a large enterprise application. The application has a 'Dashboard' view, consisting of tiles, each of which display different types of data, or different interpretations of the same data (e.g graphs, charts, maps, etc). There are filters which can narrow the data down and allow the viewer to view a more concise overview of the data set.

We have some UI tests to test the application. We are currently writing a mock backend for the tests, to ensure consistency between the test runs. For this, we are using static files which returns the JSON data we need. To mock the filtering, I have written some basic logic to filter the static data and only return the data which the user selected (e.g they selected data for London, they only get data for London).

However, my colleague is of the opinion that we should be using purely static files to serve this. So for the London location data, we'd have all of the data (e.g 10 items) in one file, and then 1 item which the user (the UI test) has selected in the filter in another file. I think this is a bit pointless as the filtered item already exists in the static file. As I said above, I wrote some basic logic to retrieve the UUID of the item selected and only return that item(s) in the response. Also, using static files means that the filtering will break if any other item is selected (as the response is hardcoded) - e.g Paris location is selected, but as the London response data is hardcoded for the filter, it shows London data (this wouldn't break the tests, as we are writing them in such a way that the front-end is unaware of/doesn't care about the data that is returned. The production backend is extensively tested separately). My method would ensure that the item selected is the item that is returned.

Which viewpoint is better/correct? To summarise - I would prefer using some basic logic in the mock backend to select the data, but my colleague wants to use purely static files.

  • 1
    I agree with your collegue: any logic can fail. The less logic your tests have the more trustwothy are they. – Timothy Truckle Mar 26 '18 at 15:33
  • Add logic for this kind of approach it's not a good idea. Soon or later, you will need to maintain also the logic from this fake API too. I know this is a temptation after some time, because will be harder to maintain some coherence between what you ask and what the services send, but this is a common problem for this kind of approach. – Dherik Mar 26 '18 at 16:04
3

Add logic it's not a good idea. Soon or later, you will need to maintain also the logic from this fake testing API too.

I know that exists a temptation to add logic there after some time, because will be harder to maintain some coherence between what you ask and what the services send in your tests. But this is a common problem for this kind of approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.