Is there any value in using abstract test classes ro run Unit and Integration testing?

I have this abstract test class

[TestFixture]
public abstract class BaseTests
{

       private IRepository _repository;

        public BaseTests(IRepository repository)
        {
            _repository = repository;
        }

        [Test]
        public virtual void CanGetResultsFr开发者_JS百科omSearch()
        {
            var results = _repository.GetResults("test");
            Assert.IsTrue(results.Count() > 0);
        }
}

Is there any value in executing the Base Tests as part of Unit Testing and also Integration testings. e.g

[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 value in repeating the test twice? I am a bit unclear if this particular test is a concern of the integration test? i.e Should integration tests be testing public methods on a class? Or should it be more into testing the functionality of the system? Or Both?!

As your examples are written, it definitely makes sense to run both test suites as they would be testing two different things.

In the first case, it tests your System Under Test (SUT) against a Fake database.

In the second case, it tests your SUT against a real database.

At the very least, these tests will verify that the SUT doesn't violate the Liskov Substitution Principle.

There are other advantages, though: Your product is probably not going to run against a Fake database in production, so the Integration Tests give you a better indication of whether the code works as intended. However, running the Integration Tests will probably be much slower than running the unit test suite, so even if the unit test suite is not a realistic scenario, it will give you more rapid feedback about the state of the code.

I'm one of the evil sort that think a unit can be expanded to include a database, so take this with the grain of salt you would with any other weirdo.

I see no point in repeating the tests or even running a unit test on the data layer with a completely mocked database in most cases (one exception being error conditions).

Do you mind if I ask what GetResults would look like for FakeReposistory? Or is that a simplification and it is really new SqlReposistory(mockedConnection)?