Unit Testing - not testable code converted to testable code

Question

I read so many places that if your code is not tested, it means the code is poorly written. So I'm starting to write code that can be tested, and start using some kind of unit testing system.

With this, although I am starting to look for some example with a piece of code that is not tested and is gradually converted to the tested code. I find a lot of examples on unit testing, but if someone can provide an example, for example, above, he probably can start something from me.

TIA

Answer 1

Put a bunch of code in the button click event and try unit test it. This is not impossible, but will either be non-trivial or require some copying to do this.

protected void buttonClick(object sender, EventArgs e) { string currUser = User.Identity.Name.ToString().Trim() .Substring(User.Identity.Name.ToString().Trim() .IndexOf("\\") + 1); Inventory.Employee.DB objEmpDB = new Inventory.Employee.DB(); Inventory.Employee.Details objEmpDetails = new Inventory.Employee.Details(); objEmpDetails = objEmpDB.Get(currUser); Welcome.Text = "Current User: " + objEmpDetails.Employee_Full_Name; var objUserDetails = new Inventory.User.Details(); Inventory.User.DB objUserDB = new Inventory.User.DB(); if (objUserDB.UserAuthenticates(currUser)) { objUserDetails = objUserDB.Get(currUser); currUserToken = objUserDetails.User_Token.Value; userID.Text = currUser; if (objUserDetails.Active_User_Name != objUserDetails.User_Name) { lShadow.Text = "Showin: " + objUserDetails.Active_User_Name; lServer.Text = "(" + objUserDB.UserPermissionName(objUserDetails.Active_Logon_Name) + ") - " + System.Environment.MachineName; lShadow.ToolTip = Inventory.Properties.Settings.Default .connectionString.Substring(0, Inventory.Properties .Settings.Default.connectionString.IndexOf(';')); divShadow.Visible = true; } else divShadow.Visible = false; lWelcome.Text = "Current User: " + objUserDetails.User_Name; } } 

Not only is this difficult due to the complexity of emulating a click of a user button, but see how much happens in that button. If your unit test fails, there are about 100 errors that could go wrong. DRY, one problem and other design principles lead to easy testing and easy code fixing. In the end, what is the use of unit test if you are testing teams, not units :)

UPDATE: (How to fix the above code)
I am not going to pretend that the code above is a simple solution. This is a “small” sample from the code base that I worked on in the past. I wanted to show how bad things can get in real life.

There are two main problems with the code.

• It is difficult to verify by pressing the Events button.
• There are too many in one way.

Easily fix an event driven / reproducing a problem with the click of a button. You can wrap all this code in another way:

 protected void buttonClick(object sender, EventArgs e) { EasyToCallMethod(); } public void EasyToCallMethod() { string currUser = User.Identity.Name.ToString().Trim() .Substring(User.Identity.Name.ToString().Trim().IndexOf("\\") + 1); //...rest of code } 

Now it is easy to call from unit test. But, this is a little stupid, because it really does not solve the second problem.

Easy fix
So, there are good 15-20 tests that we can make from this method. Just do a test for each line that has a specific purpose (for example, when calling a method), and you should have good unit tests that are small enough to tell where something broke and good code coverage.
Advanced material
Much more work can be done. We can implement n-tier MVC or MVVM. At some point you should ask yourself if you are excessive. Unit tests should make your code more serviceable, but don't cross out into nothing. This is where your own style and experience comes into play. When you feel that you have the basics, you should return to SO with new questions or take a good book.

Answer 2

Here are two great books to help you get started:

• The art of device testing
• Works efficiently with legacy code

Good luck.

Answer 3

I do not agree completely. For example, suppose you have a program that does things based on a timer. If you want to check it in a deterministic way, you have to change and pause the system clock. There is a lot of literature on deterministic testing of time. So everything can be checked, the question is how easy it is. And it does not depend on how well the code is written, it depends on the actual task that the program performs and how it was developed, and not implemented. Even with a good design, you can get code that is difficult to verify.

Answer 4

The most important key factor to make code more (unit-) testable is dependency injection.

The first chapter of the book by Mark Semann

Dependency Injection in .NET

freely available here http://www.manning.com/seemann/ as a PDF file. It contains a very complete example of how to make part of closely related code more reliable by reducing dependency on lower levels.