Is there any value in using abstract ro run Unit and Integration testing test classes?
I have this abstract test class
[TestFixture]
public abstract class BaseTests
{
private IRepository _repository;
public BaseTests(IRepository repository)
{
_repository = repository;
}
[Test]
public virtual void CanGetResultsFromSearch()
{
var results = _repository.GetResults("test");
Assert.IsTrue(results.Count() > 0);
}
}
Is there any value in doing baseline tests as part of unit testing as well as integration testing. eg
[TestFixture]
public class UnitTest : BaseTests
{
private static IRepository _repository = new FakeReposistory();
public UnitTest() : base(_repository)
{
}
}
[TestFixture]
public class IntegrationTest : BaseTests
{
private static IRepository _repository = new SqlReposistory();
public UnitTest() : base(_repository)
{
}
}
Is there a value for repeating the test twice? I'm a bit unclear if this particular test is an integration test issue? i. Should integration testing be testing public methods in a class? Or should it be more in testing the functionality of the system? Or Both ?!
As your examples are written, it definitely makes sense to run both test suites as they will test two different things.
In the first case, it checks your system test (SUT) against the Fake database.
In the second case, it checks your SUT against a valid database.
At the very least, these tests will confirm that the SUT does not violate the Liskov Substitution Principle.
There are other benefits as well: your product probably won't work against a Fake database in production, so integration tests give you a better idea of whether your code is working as intended. However, running integration tests will probably be much slower than running a unit test package, so even if a unit test package is not a realistic scenario, it will give you faster code status feedback.
source to share
I am one of the wicked varieties that think the division can be expanded to include a database, so take that with a grain of salt you could with any other weirdo.
I see no point in repeating tests or even running a unit test on the data tier with a completely mocked database in most cases (except for error conditions).
Mind if I ask what will look like GetResults
for FakeReposistory
? Or is it a simplification, and is it really new SqlReposistory(mockedConnection)
?
source to share