How can I integrate testing into my code written using the ASP.NET provider model?
I am new to unit testing. I have a site built in 3-tier architecture, UI -> BLL -> DAL. And I was using the asp.net provider model, so by making changes to the web.config, I can switch to the dll dll to target different data sources to be complete, the DAL is written with Entity Framework.
Now, my question is, how do I unit test my BLL? I am using NUnit.
If you run / debug my site asp.net/IIS loads everything and gets the correct config from web.config, so everything works because the entry point is from IIS. Now if I use the NUnit gui for testing and say that I have a test project "MySite.Test.dll" that has test cases for my BLL, how does the test framework get the correct configuration to run the whole test successfully. To load the correct provider, you need information in the web.config!
Now my DAL has an App.config created there by EntityFramework and it only has a connectionString in it. Should I put all provider related config in this app.config? Or am I missing some big picture on how to do this correctly?
It should be common I think people need to do it all the time. Can someone give some details on how I unit test my lib.
Thanks Ray.
Edit: After reading the first 2 answers, I think I should correct my description with integration testing. Basically instead of IIS as the entry point, use GUI tools like NUnit to run and inspect my code, so NUnit -> BLL -> DAL. How do people really customize it?
Thanks Ray.
source to share
It looks like what you are trying to do is integration testing ... Unit testing is, by definition, testing regular .Net classes in isolation. No database, no configuration ... so as I see it, for proper unit testing, you need to refactor the BLL into service level and domain classes that you will test separately. For example: The service layer uses domain logic classes and your unit test uses them. This way the domain classes don't end up in the database and you don't need connection strings and that's it.
However, if you want to do proper database integration testing, you can do that as well. If this is what you want - google, it is not difficult to get some config lines in the nunit.config file or something ... I don't know the details.
However, I feel that you want to do this unit testing, not integration testing.
Ask yourself WHAT EXACTLY DO I WANT TO EXPERIENCE? Unit testing does not test "everything". Refactor, invert dependencies, and try to test your business logic in isolation.
source to share
Instead of the "web.config" file in your unit test project, you need the "MySite.Test.dll.config" file, which you can instead enter the correct configuration for testing. Note that with this method, you could use a different provider to connect to the in-memory database if you like.
source to share
You have several different options depending on how isolated you are from the DAL. If you want to include DAL in your tests, you can copy the connection string of the app.config file to the app.config file in your unit test project. However, as Babadboy argues, this is really integration testing, not unit testing.
If you want to do proper unit testing, you probably want to use dependency injection and interfaces to allow you to mock the DAL from your BLL. I am using LINQ-to-SQL, so I am creating an interface and wrapper class around the DataContext. This allows me to create a layout database to use for unit testing to test my object classes in isolation.
Testing your object classes in isolation will make your tests less fragile and allow you to customize the data for each test yourself. This simplifies maintenance.
You might also want to take a look at a mocking framework that makes it almost trivial to create mock objects. I have had very good success with Rhino Mocks, but there are others.
source to share