Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
How to do TDD/BDD with asp.net 4.0 Web Forms? I have an existing website that has very large scale and we dont have any test with each change in database we have to guess what will break? I want to introduce unit testing please give me pointers?
A lot will depend on how your existing codebase is structured.
It can take a lot of work to retrofit Unit testing and especially TDD into a legacy project. Typically you’ll find database and business logic residing in the code behind file of the web pages.
Use of interface types are your friend here as Visual Studio can generate Interface classes automatically for you. (Place the cursor over a class name, right click, select refactor and extract interface)
I would work towards separating your database code into a class library project of it’s own. You can then specify the public interface through which the business logic etc can access the database. All other code should treat the database repository as a black box.
Create a factory to make your repository (based on that Interface), have it create a test type and a live type. The live type will link into your current database code. The test type will just return hard coded values. You can write tests using the live database, then you can write tests for the “test” database in a TDD manner.
Once they both match (all tests pass) any new database functionality is added by writing the test that runs on the “test” database first and then on the live database.
Remember all code should only use the Interface to the database not an instantiated live database class.
Once you’ve got the hang of the process you can delve deeper (if you wish) within the database code, but I would say that following the same process in separating and testing business and UI logic is more practical on a legacy project.
You may find that a pragmatic approach is to only separate out functionality following the process that I’ve described as you go to add new code. In other words before you add new functionality, separate out the code as described writing the tests that show that it passes (live and test version) then alter or add test for new functionality using whether the test passes or fails to guide your coding.
If covering all bases you want a test for failure, test for pass and maybe a test for exception scenario.
Good luck. It’s not a job for the faint hearted (having had to do it many times in the past).