What practices are used to avoid constantly testing the login screen?
Good tests shouldn't shouldn't have duplication and should be concise, however when testing a web application with authentication the test must first get past authentication to perform the desired function. With many tests this quickly means that the login screen (or equivalent) will be tested numerous times. I would ideally like to avoid this repetition. One method is to create cookies and sessions to "trick" the browser into thinking the state for the test exists. This method quickly becomes complex with potentially many sessions needing to be created, and also increases the overhead of the test, especially if these need to be combined with database states. Does anyone have a good solution for a complex applications, or a good pattern for managing multiple sessions, databases, and cookies if this is how they work?
If I understand correctly, you are looking at ways to make your tests more efficient, so you can get as quickly as possible to the desired state and then perform the actual assertion that the test case is intended to cover. There are a couple of options you have: Use a class setup method, or application setup method to log in, then re-use your existing, open web browser to execute each test case. You may also need a corresponding cleanup method to execute at the end of each test to get you to a known state for the start of your test case. Most test runners support this, you would need to refer to the documentation of your particular test runner to get syntax. Incorporate an http library to bypass the UI and send an HTTP request to log in, then set the session cookie value with webdriver's addCookie method so when you navigate to a specific page within your app, you will already be logged in. If you have other crud operations within your app, you can also have non UI versions of those actions as well. I have used this approach for creating new users, creating any kind of user specific content, etc, and have used it in my cleanup methods to delete content at the end of each test case, or test class. This saves time, and is usually more reliable than going through the UI. This is very useful when you have a test case where you want to assert on some behavior on a page showing details about some user created object (let's say an event in a calendar) and that event can have lots of different properties. Since you already have a test to create the calendar event through the UI, you don't need to do it over and over again for all of the tests that require an existing one, so you can send an http request to create the calendar event, then navigate to the page to view the event and execute your test assertion using the UI.