1

I've read the following posts:

Is there a way to run MySQL in-memory for JUnit test cases?

Stubbing / mocking a database in .Net

SQL server stub for java

They seem to address unit/component level testing (or have no answers), but I'm doing system testing of an application which has few test hooks. I have a RESTful web service backed by a database with JPA. I'm using NUnit to run tests against the API, but those tests often need complex data setup and teardown. To reduce the cost of doing this within a test via API calls, I would like to create (ideally in memory) databases which can be connected to via a DB provider using a connection string. The idea would be to have a test resource management service which builds databases of specific types, allowing a test to re-point the SUT to a new database with the expected data when it starts - one which can simply be dropped on teardown.

Is there a way, using Oracle or MSSQL, to create a database in memory (could be something as simple as a C# DataSet) which the web server can talk to as if it were a production database? Quick/cheap creation and disposal would be as good as in memory, to be honest.

I feel like this is a question that should have an answer already, but can't find it/ don't understand enough to know that I've found it.

Community
  • 1
  • 1
Orphid
  • 2,722
  • 2
  • 27
  • 41
  • 2
    If you abstract the database access behind the repository pattern, then you can just provide a in memory repository instance for testing. – Sriram Sakthivel Jan 12 '16 at 18:00
  • @SriramSakthivel Would that require access to the SUTs codebase? If so, I'd ideally like to find a solution that doesn't require that. I'm not sure I understand what you are saying, but are you talking about mocking the persistent abstraction layer (JPA) rather than the database itself? Would you be able to point me to any guides so I can understand the process more fully? – Orphid Jan 12 '16 at 18:05
  • 2
    Yes exactly. I'm talking about mocking the data access layer rather than the database itself just because it is easier. Yes it requires to modify your SUT to use repository pattern rather than directly using database somehow. Mocking the repository should be easy; you can provide a implementation which is backed by a in memory List. Something [like this](http://www.williablog.net/williablog/post/2009/12/15/Mock-a-database-repository-using-Moq.aspx) except that it uses moq, you can provide your own implementation for system testing without any testing framework or mocking framework dependency. – Sriram Sakthivel Jan 12 '16 at 18:13

0 Answers0