1

I have a test method, using NUnit and Selenium, which opens a browser on our website which is on the Production Server and registers a user and verifies that the registration is successful.

(I know ideally the system tests should run on a separate Test Server rather than production but here they want to test whether the prod system works!)

The problem is how to rollback the database changes as a result of this test? For example, the state of my database before and after running the state should be the same.

I thought of 3 possible options but none is practical:

1) writing SQL queries to delete from the actual tables before starting the test (Setup) and after running the test (TearDown); this is my current approach however The problem with this approach is that I have to know exactly which tables were involved for each System Test which runs and this can quickly become very complex as a test may impact more than one table.

2) Writing transactional Code This is not an option since the code changes are done by the website, not by the unit test written.

3) Getting an snapshot of existing database (SQL Server 2008 R2) before each test starts then after the test finished, restoring the snapshot to the original one. This idea sounds good to me if we could run the tests only on Staging environment but the problem is that the tests have to run on Production and may take like 5 minutes totally so rolling it back and restoring it, would be a stupid idea as the changes done in that 5 minutes would be lost!

Please advise what approach would be best possible option to resolve this problem? there may be a 4th option?

Thanks,

Michael Lloyd Lee mlk
  • 14,561
  • 3
  • 44
  • 81
The Light
  • 26,341
  • 62
  • 176
  • 258
  • 2
    I think an interesting question here is, why do you (or your team) not trust your test environment? Perhaps the best solution of all would be to ensure that your team is confident that test is a fully accurate representation of production? Otherwise, what's the point of having a test environment? – Pondlife Mar 16 '12 at 10:21
  • To know whether the prod environment works and is live as expected. Staging is used for other types of tests by the business team, the tests that can't be done on Prod. I know it's a bit confusing! – The Light Mar 19 '12 at 13:25

3 Answers3

5

Option 4 never ever ever ever do tests on a production server it's a recipe for disaster (see thousands of funny (if you are not the protagonist) stories on the internet on how this could go horribly wrong), the right thing to do would be to configure the test and production server in the same way.

angelodiego
  • 245
  • 1
  • 16
  • 1
    I can imagine why he wants to do it - its better to find out right after deployment that something is not working than let users report it... – Pavel Janicek Mar 16 '12 at 10:36
  • Ok, imagine the tests were running against Staging, now which approach would you recommend and why? thanks. – The Light Mar 19 '12 at 13:36
  • Simply rebuild, repopulate the staging site every time you have a stack of modification that you have to put in production – angelodiego Mar 26 '12 at 08:05
0

There is a fith option. If the website receives a registration for user "WeAreTestingOutSite" it does everything except for actually adding the user to the Database.

To be honest, as was said, there are better ways to test if a production site is still in operation than to run bots to register a user to make sure it is working (or operational).

Jaques
  • 2,215
  • 1
  • 18
  • 35
  • Ok, imagine the tests were running against Staging, now which approach would you recommend and why? thanks. – The Light Mar 19 '12 at 13:37
-1

I would recommend you going with 4th option: Introduce new feature which allows to delete the user. Probably not to the user himself/herself but to the system admins (Backoffice users). That way you can test if user can be registered - and deleted afterwards while not caring that much about the SQL scripts.

Pavel Janicek
  • 14,128
  • 14
  • 53
  • 77