Unit Test Case SqlDistributedLock Mocking ConnectionString

[madelson]

Unit Test Case SqlDistributedLock Mocking ConnectionString

[madelson]

Hi @karthik6244 thanks for your interest in the library.

As I see it, you have two main options:

1. Use a real database: rather than mocking a lock connection, it is often easy to just use a real one. For example, you could simply rely on a local instance of SqlExpress existing:

new SqlConnectionStringBuilder { DataSource = @".\SQLEXPRESS", InitialCatalog = "master", IntegratedSecurity = true }.ConnectionString

2. Create an abstraction around the features you use and mock that:

interface IDistributedLock { ... }

Depending on what you're trying to test, you'll likely want the fake implementation you swap in to actually behave like a lock. I'd probably recommend using the SystemDistributedLock class which ships with the library for this purpose (see https://github.com/madelson/DistributedLock#system-wide-locks), but you could also use something like SemaphoreSlim if you want to isolate 100% to the test process (the system lock isolates to the test process machine, which is the same isolation as using SqlExpress except with no dependency on a SqlExpress install).

Personally, I'd recommend using SqlExpress (or another available real database) because this makes your test more realistic in the sense that you are testing against real SQL locking behavior and semantics. By faking out the locking layer, you risk having code that passes the test but exhibits bugs when the SQL semantics are applied.

Let me know if that helps!