0

For example I have a simple on-line shop. The user can add a product with and without tags.

I would like to test it functionally.

My first test:

  1. Generate sample data to database (User)
  2. User login to panel.
  3. User go to /add-product page.
  4. User added new product without tags.
  5. Check if produduct without tags exists on the homepage.
  6. Truncate database.

My second test:

  1. Generate sample data to database (User)
  2. User login to panel.
  3. User go to /add-product page.
  4. User added new product with tags.
  5. Check if product with tags exists on the homepage.
  6. Truncate database.

My third test:

  1. Generate sample data to database (User)
  2. User login to panel.
  3. User go to /add-product page.
  4. User added new product without tags.
  5. Check if product without tags exists on the homepage.
  6. User go to /edit-product page.
  7. User add new tags.
  8. Check if product with tags exists on the homepage.
  9. Truncate database.

The first three steps (and last are identical) and the next two are very similar. 6, 7 and 8 are only in the third test.

Is this a good way of testing? Maybe I should shorten it somehow?

1
  • Why this tag functionality needs to be tested on top UI layer as E2E tests with all PERMUTATIONS? Commented Oct 21, 2018 at 23:58

1 Answer 1

1

For a healthy and reliable test suite, you need to understand what is being tested, and use the right tools for it.

For instance, the login feature is completely separated from the actions inside the app. So, you create a test for it.

Now, considering the above, for the user actions inside the app, you will want to isolate yourself from problems with the login. Why? Because if you do not mock the login, any problem with the login will block further tests - you will not know if you have only a problem with the login or if you have both problems with the login and with some user action.

This isolation can be done by having a endpoint activated only on test environments which will generate some sort of token that will simulate the login when you go to some page.

For tests (1) and (2), you have the following:

1 - User added new product xxx.

2 - Check if product xxx on the homepage.

The step 1 is composed of three tests:

1 - You want to check that that the user can act in a certain way with the frontend and it will send a request with some data. This is a frontend test, isolating it from the backend.

2 - You want to check if the backend, upon receiving the request which says to save a certain product will actually save the data in the database. This is a backend/service test, isolating it from the frontend.

3 - You want to check if the mocked requests that both frontend and backend are identical. This is a contract test.

Step 2 is purely a frontend test: You will feed the frontend app with a request which simulates a response with certain characteristics and checks if the frontend renders this data correctly.

Test (3) only adds the edition:

  • "User add new tags":
    • One frontend test which receives a mocked response with product data, act upon the rendered page, and checks if the edition request is sent correctly.
    • One backend test which sets up the database with a given product data, send an edition request, and checks if the database was updated correctly.
    • Contract test for the edition request.

The end-to-end tests required here are to check if the building process is correct, linking the frontend correctly to the backend.

Only one end-to-end test is necessary: - Setup a product on the backend; - User logins; - User sees the product on the page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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