I'm automating a web application and I have 2 things there :

  1. An administrator side, typically used for creating users, managing users, modifying the content etc (the list goes on)

  2. A user login side to view such content etc.

How do I handle the automated testing for this? do I start by setting up the test via the administrator UI to create a user, then navigate to the user side, login and verify what I need?


Would you typically setup the test by inserting a user into the database and using them for any user-side tests? Inserting via the DB for any administrators when testing that side?

I'm confused on where the flow of a test should truly begin,

  • Login as admin
  • Create user, setup appropriate privs all via UI
  • Login as said user, execute the test
  • Verify the results

Seems very long winded, should i just setup a user in the DB as step 1 and then verify any user-side functionality that way ? repeating the above for the administrator side and never doing a full flow through both sides if that makes sense?

1 Answer 1


It depends

If your application has an API, handle all the permissions and business logic through API tests. They're faster.

My approach, assuming that I had the ability to restore a test database to use as my oracle would be:

  • Restore database as part of the test run setup. The database should have all user accounts needed for the main tests, as well as some content to use for edit tests so that every test is independent.
  • Group back-end and front-end tests. Run the administrator tests as one test set, and the front end tests as a second set. It's up to you whether you use the same database or not.
  • If possible, anything that permanently changes data should be an API test. Creating your user, validating content, editing users... the outcome of these actions should be API tests rather than UI tests. If possible, your tests from the UI end should focus on things like UI validation, required fields, and so forth.
  • Extract navigation into helper routines. Your tests will be cluttered if you try to include login and navigation to your target page as part of the test, particularly since you're going to be doing a lot of similar actions there. Use helper routines and/or POM methods.
  • Automated full flow tests should be minimal. At most one or two tests to cover the end-to-end functionality - the actions of loading multiple pages, entering data, saving, logging in, and logging out, will add a lot of time to your tests when you try to bring them all together.

This assumes that you're testing a well-designed application where the UI uses API calls to communicate with the back end. If your application is less modular and has the business logic tangled with the UI, you may have no choice about running a lot of end-to-end UI tests.

  • that is some great info thanks Kate, sadly the business logic is heavily tangled with the UI so i'm going to distribute widely across chrome instances on GRID and have quite a few tests, ive been restoring a sql server .db at the start of each run and using that starting state to keep the tests independent
    – symon
    Aug 15, 2017 at 19:11
  • could you elaborate more on the integration/API tests, I get confused on what you refer too those a little. by that do you mean running headless with something like REST ASSURED to some degree and verify HTML in the response etc/Posting to the backend via HTTP methods etc but without the act of rendering it all in a browser?
    – symon
    Aug 15, 2017 at 19:31
  • 1
    @symon, I'm talking about connecting directly to a REST or other API and calling its methods rather than running through HTML request/responses
    – Kate Paulk
    Aug 15, 2017 at 19:47
  • great thanks, could you help me picture what a scenario might look like for an integration login test then? HTTP GET the login page, POST the data for login to the server, verify i've been redirected to a /index page? what does this assertation look like, am I checking HTML in the response body and asserting against it?
    – symon
    Aug 16, 2017 at 7:21

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.