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

Documentation to Deal with dependency injection for Unit tests #386

Open
paillave opened this issue Oct 28, 2022 Discussed in #385 · 1 comment
Open

Documentation to Deal with dependency injection for Unit tests #386

paillave opened this issue Oct 28, 2022 Discussed in #385 · 1 comment
Assignees
Labels
documentation Documentation may be added or completed on the portal question Further information is requested

Comments

@paillave
Copy link
Owner

Discussed in #385

Originally posted by mlholt03 October 17, 2022
If I am access a database using this tool, and I wish to write unit tests for the code I am writing, how can I mock out the database access such that my unit test is not actually attempting to connect to a database? Is there some way to provide a SqlCommandValueProvider instance that simply returns a basic sample set of data without querying a database?

@paillave paillave added question Further information is requested documentation Documentation may be added or completed on the portal labels Oct 28, 2022
@paillave paillave self-assigned this Oct 28, 2022
@paillave
Copy link
Owner Author

About mocking and unit tests, the solutions are the same than the ones you use for regular NET development.
At the moment, no there is no such things like SqlCommandValueProvider that returns data without querying the database. The ways you can do are the ones described in here:
https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database?source=recommendations

EF core In memory provider

https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database?source=recommendations#in-memory-provider

Instead of injecting a DbContext that uses SQL Server, you inject a DBContext setup to work in memory instead

SQL Lite in memory

https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database?source=recommendations#sqlite-in-memory

Instead of injecting a DbContext that uses SQL Server, you inject a DBContext setup to work with SQL lite by giving a connecting string that is setup to work in memory.

Repository

https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database?source=recommendations#repository-pattern

In the same way you inject a DbConnection or a DbContext into ETL.NET, you can inject anything you want (Services or Repositories for instance).

Then, within your process, you can use what was injected by using ResolveAndSelect or ResolveAndDo operators.

If you have a business layer that you want to reuse within a stream, this is the way to go.

FYI: I change this conversation into an issue to remind me to improve the documentation regarding DI in processes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Documentation may be added or completed on the portal question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant