0

I have in project linq repository unit tests.

    [Fact]
    public async Task Get_FromTreeEntitiesUnsorted_RetunsOrderByDescending()
    {
        //Arrange
        _contextReadonly.Entity.Add(new Entity { Id = 1, Source = "1", Date = DateTime.Now.AddDays(1) });
        _contextReadonly.Entity.Add(new Entity { Id = 2, Source = "2", Date = DateTime.Now });
        _contextReadonly.Entity.Add(new Entity { Id = 3, Source = "3", Date = DateTime.Now.AddDays(2) });
        _contextReadonly.SaveChanges();

        //Act
        var queryResult = await _repository.GetEntitiesAsync(1, 5);

        //Assert
        queryResult.Should().HaveCount(3);
        queryResult[0].Source.Should().Be("3");
        queryResult[1].Source.Should().Be("1");
        queryResult[2].Source.Should().Be("2");
    }

We have started to encrypt some data using https://github.com/Eastrall/EntityFrameworkCore.DataEncryption

    public MyContext(DbContextOptions<MyContext> options) : base(options)
    {

        var keyBase = System.Text.Encoding.UTF8.GetBytes("Y");
        var keyIv = System.Text.Encoding.UTF8.GetBytes("X");
        _provider = new AesProvider(keyBase, keyIv);
    }

Now i started to think should data in unit tests be encrypted/decrypted (because it start to be a bit of integration tests) or i should mock it somehow

EDIT:

All values in tests are decrypted data. Encryption/Decryption is handled by external library and EF Core.

2
  • Where is the encryption/decryption handled? Does your Repository code have to do it, or is it handled transparently by the DbContext? Commented Feb 21 at 10:03
  • @BartvanIngenSchenau As OP writes in the question. He is using EF Core library, that handles encryption transparently within DBContext.
    – Euphoric
    Commented Feb 21 at 12:39

2 Answers 2

3

My opinion is to not bother with encryption in business-facing tests, but test it in integration tests that verify validity of schema againts real database.

Usually, I have two sets of tests. One that use in-memory EF for Context, which are for testing business behavior. In this scenario, using encryption feels uneccessary. Business code doesn't care if username or password is encrypted or not.

Second set of tests runs Context against database running in testcontainers. But these mostly verify if the schema works correctly against migrations or if queries are doing what is expected of them. This is where I would include the encryption. You would make sure that the schema supports it and that encryption works correctly both when saving and retrieving data.

2

Yes, if the context returns encrypted data which is then decoded in the repository you mocked repository should also contain encrypted data. Otherwise the test will fail.

If the encryption itself can be mocked and injected then you have a choice. But I think i would test with the encryption either way

If the repository returns decrypted data, then your mocked one should return decrypted data. But I would make sure I had an integration test in this case.

In fact, with the ease of spinning up databases in containers these days I would not bother with a mocked context at all and just write integration tests using a real containerised DB spun up just for the tests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.