These are questions about browser testing and state.
Imagine a large suite of browser tests that intend to deeply regression test an application. Like most web apps, this involves different types of state: user permissions, expected data in a database, etc. Testing the application requires logging in as different users and/or user types to test different views into the data.
- What are patterns for creating expected state prior to running browser tests?
- Is it appropriate for the browser tests to communicate directly with the database of the system under test, creating state in the same manner that you would in an integration test?
- How important is it that browser tests be decoupled from the application under test, such that the only thing required to run tests are the tests themselves, which can be pointed at any applicable URL (dev, test, staging)?
Just two cents from me:
There are multiple ways to create the state of the app that you wish, if you can have majority of your tests and parts of the stack running locally on your machine, then you can write majority of non full integration tests to chip away at smaller parts of the application. Yes the orders service or the integration with 3rd party tests might not work, but at least you can test your application alone in a hermetic environment, this will provide a really consistent test results. In my opinion, the purer your application is, that is no external input, the more useful the test results are.
As for the direct communication with the DB, there are several options
If you are running tests locally, there is no problem with generating and loading fixtures into DB as part of the pre-build process. This way your tests know the exact state of the app every single time
On integration environments, i've used a smaller sub-sample of the prod DB (with customer data obfuscated), this way the MySQL dump loaded post each deploy of new build unto integration environment, and can also be parsed by your tests to know the current state of the application
In situations where the DB cannot be easily manipulated pre build or post deploy, such as staging, i've used the native mobile app's API to get access to some of the data on the environment, such as product listing etc. This way being most limited and READ ONLY compared to the previous options.
As for the coupling, i don't think i can give a coherent response to that question at the moment.