Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unit Test Case SqlDistributedLock Mocking ConnectionString #21

Closed
karthik6244 opened this issue Nov 30, 2018 · 1 comment
Closed

Unit Test Case SqlDistributedLock Mocking ConnectionString #21

karthik6244 opened this issue Nov 30, 2018 · 1 comment
Labels

Comments

@karthik6244
Copy link

For one of my requirement I'm using SqlDistributedLock() passing lockName, ConnectionString. Its working fine. However I want to write unit testcase for this behavior, how can i mock the connectionString, It's failing there.

@madelson
Copy link
Owner

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
  1. 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants