1

Given: The application I am testing , has functionality to create the data, would altering/inserting the/to database be a good way to create test data.

  1. IF you think of the speed of the application/complexity of database what would be the best way?
  2. Are there any alternative ways?
Asanke
  • 551
  • 1
  • 11
  • 32

2 Answers2

1

You can mock the database so the actual database will never be touched but all the functions can be tested on the mock database.

Janitha Tennakoon
  • 856
  • 11
  • 40
0

best way is to refactor your code so that any logic is decoupled from executing database query. then split tests into unit tests and integration tests. in unit tests you mock your database and test your logic. in integration tests you test only database part, without touching any other high level components. to do it correctly you should run tests against you real database. if you think about any optimisations that you can think about supporting also another, faster, database (in-memory one). then you can your db tests frequently using in-memory db and then just once (or only a few times) run tests against your real database. but to set up and maintain environment and configuration for different dbs is time consuming so you have to calculate which takes more time in your case

piotrek
  • 13,982
  • 13
  • 79
  • 165
  • Thank you! I am far away from altering the application and the way its being deployed/integrated. The pain here is to create some database data , I have to spend quite a time if I am to follow the actual workflow. Here I am seeking a way to cut this shorter without compromising the purpose of testing. – Asanke Feb 14 '15 at 21:53
  • 1
    i advise not to create data for whole workflow (unless you're planning integration tests) but to create data for each test inside that test. for this purpose you can use the same technique you use in your production code - simply insert data before executing the tested function. but to do it, you need cleanly separated database code from rest of the logic – piotrek Feb 14 '15 at 22:01
  • That makes sense. For a given scenario, If the number of records and the complexity of the data is low this will be a good option. What do you mean by "you need cleanly separated database code from rest of the logic" ?? – Asanke Feb 15 '15 at 03:12
  • 1
    by separation i mean that you should have a component that takes parameters (name, surname, date etc), put them into a query and executes that query. getting parameters from session, doing time calculations, checking permissions etc should be done elsewhere. this way your expensive database tests will be small and you will be able to reduce number of those tests – piotrek Feb 15 '15 at 13:08