编码的UI测试

Question

I want to automate some testing using coded ui testing. Some of my tests involve making transactions against a database that I want to assert things from. But running these automated tests introduce their own issues, everytime the test runs it could be modifying (adding, updating, or removing records) the state of my database. Is there some general guidance how to create coded ui tests when modifying a database? Do I want to add mock repositories? Do I want to create a test environment that has a database server that can be reverted to snapshot with each test run? Should coded ui testing not involve asserting values from a database transaction and instead just assert a button was clicked and have unit testing assert the database transactions?

Answer 1

IMHO this question applies to any test you write - not only specifically to CodedUI tests.

Your tests could Query/ExecuteNonQuery on a db as they progress. So the DB would move from state A to state B by the end of the test run. Therefore its good to make sure that you have some DB refresh scripts run at the start of the test run so you can make sure that you brought the db into State A before the run irrespective its current state.

Its probably good to note that when you run the same tests on the same test data with the DB state remaining the same at the start of the test run, you are performing the exact same test each time and the chances are the application under test has become immune to those tests and the test run ends up with diminishing returns over time. So its probably a good idea to randomize the test data on which the tests work.

Answer 2

It can be as simple or as complicated as you want it.

Simplest approach is to completely reset the data with each run. This might mean creating the db from scratch each time using some schema creation script.

A more complicated solution would be to only reset parts of the schema (ie: certain tables, depending on the nature of the test). Related tables, etc.

Whatever you do - it's bad practice to expect the tests to run in a certain order. If you have 50 tests as part of your suite, these tests must be capable of running in any order, and run according to the tester - who might decide to run 1 or all of your tests.

That's the high level stuff. In terms of actual implementation, you can find interesting ways to mark tests with attributes and there you can define values of what you will initialize (this could be table names to clear, or if you're working with an ORM could be 1 entity, and from there dynamically determine related tables. And run clean outs dynamically.