April 2008 - Posts
While I am a big fan of unit testing I often try to point out that Code Coverage tells us little more than “are there unit tests” not “are we unit testing”. The former indicates that the code is indeed being executed. The latter indicates that the code is being exercised.
Scott Hanselman describes this in a podcast available here:
http://www.hanselman.com/blog/HanselminutesPodcast103QuetzalBradleyOnTestingAfterUnitTestsAndTheMythOfCodeCoverage.aspx
I personally think testing really needs to be evolved to the level our architecture and code. Testing frameworks are clumsy and it is very difficult to all of our code. Most people are quick to point out that unit testing UI is difficult and usually yields the least amount of benefit. Depending on the architecture and implementation of that specific application, that may well be true.
Two other major hurtles that are well known. First, when we unit test we want as “authentic” of a test as we can get. This includes the data. How much time and effort do we spend getting authentic data to our unit tests or providing an abstracted data layer for our code to operate on? This is a big problem not just because of the hours it takes to provide such data abstraction implementations but because the time it takes to run Unit Tests is greatly increased. I argue this because I believe that when unit testing takes 30 min’s to complete, developers are not going to run them before checking in, and that I believe is an issue.
The other major unit testing hurdle is the concept of the “Oracle” as described by Scott. This term simply refers to the ability of a piece of code to assert that a test has indeed run in such a way that an end user is going to get what they expect. Some of these sceneries can be very complex and it is impossible to test for all permutations of a given rule.
What do I think is needed in Unit Testing?
- The disparity between code and “UI” needs to be removed! It needs to be no harder to test a piece of UI then a API Class Library.
- Unit testing “language” needs to be more declarative and functional. I need to be able to test a wide variety of test scenarios quickly and easily. Functional languages are good at this. I do not suggest that we adopt Python for unit testing but maybe a testing language developed for this purpose.
- There needs to be a healthy attitude toward testing in the industry. I watch every day at any place I go where people “fix” the code in production. If they had better testing before the code went to production they could have easily caught these errors! A production line is down for an entire day, but if you ask -- no one can afford
- There needs to be more automation in Unit Testing. For example, can’t the computer automatically generate tests for the edge cases? Coulden’t it generate input that would “execute” every branch of code possible? It may be of marginal usefulness but it would be free.
- Unit testing needs to run faster! I have long mentioned the need to use multiple threads to execute tests – I even modified a release of nUnit to run on the ThreadPoool, but these need to be adopted and standardized
- There needs to be a better way to test with real data.
Of course, the best sets of testing will not eliminate all bugs. In fact, you must adopt your own testing philosophy when in charge of a development effort. The question you have to ask yourself is two-fold. First, How important is it that my code has very few bugs. Would a bug in your software, if unchecked, cost your company a lot of money? Could a potential bug cost the company thousands, millions, billions, or even someone's life? If so, then your testing should reflect that. It's good risk management to spend 2x or more the cost of software development to avoid this type of costly loss. On the other hand, if software has little consequence other than user annoyance when a bug is present then perhaps less of the development dollars need go toward testing. In some sceneries it is completely fathomable that none of the software budget is spent on automated testing.
The other question you will need to answer is will adding automated testing to my project yield a return on investment? Before you make a snap judgement on this second point I may add that systems that have good testing in place (automated testing in particular) have a much cheaper lifecycle than applications that do not have this type of safe-guard. Automated testing is a lot like life insurance in this way. Having critical pieces of your code unit tested will save your bacon almost guaranteed!
I have been meaning to do this for years! I actually purchased this domain back in 2004--lost it for a few years and recently purchased it again. Me and some of my friends plan to support an online community where we can answer questions and post content that is useful to the community.
I have been doing Code Camp for over a year now (that may not seem like a lot but this will be my 3rd time presenting there). Code Camp is awesome! It's a full day of free training in a verity of topics that most developers find interesting.
Topics Include:
- Silverlight 2.0
- Building websites with the ASP.NET MVC framework
- C# 3.0
- Writing Manageable Services in .NET
- Database Performance tuning Part 1
- IronRuby + C# = Awesomeness
- Game Development in XNA for the Xbox360
- Introduction to Mac OS X programming using Cocoa and Objective C
- Developing For Windows Vista
- T-Sql Querying
- Why C# Namespaces are not the same as Java Packages
- An Introduction to CakePHP
You can visit http://www.utcodecamp.com for more information (Yes, I know I put the Microsoft technologies first -- I'm an unpaid unofficial self-proclaimed Microsoft Technologies Evangelist!). Wither you are just starting out in your career or have been doing this stuff for years you will get something out of Code Camp! It's not one of those Microsoft "For developers" class sessions where it's just a giant power point and you didn't get any real substance! In fact, that is part of the Code Camp Manifesto (http://blogs.msdn.com/trobbins/archive/2004/12/12/280181.aspx)
Information:
Date: April 26, 2008 (This Saturday)
Time: 9:00AM - 5:00PM
Please register here.
I will be doing the Silverlight 2.0 presentation so please come!!
Thanks!
Nathan Zaugg
I was creating a payment form recently and I wanted to disable the submit button after the user had clicked it so that there was no chance of them clicking it twice on accident.
This seems like one of those things that just ought to be a slam dunk! Back when I was doing ASP, this was one of the easiest things I ever did. I have done it with asp.net before, but I never needed validation to work as well. It took me a long time, many searches and trial and error but I found a solution that will disable the button and doesn't get in the way of validation.
protected override void OnInit(EventArgs e) { // We need this to get our button event Form.SubmitDisabledControls = true; btnProcessPayment.UseSubmitBehavior = false; // Attach javascript code to the OnClientClick event btnProcessPayment.OnClientClick = "javascript :if ( Page_ClientValidate() ) " + "{this.disabled=true; this.value='Please Wait...'};"; base.OnInit(e); }
The javascript is pretty straight-forward. We are simply calling the validation function ourselves, if it validated we disable the button and change the text. What does the rest of the code do then? Well, normally when a control is disabled it doesn't post data on postback. Fortunantly, ASP.NET makes it easy to override that default behavior. Without this data our button click event would never fire!
You can also do this in the HTML as well.
<form id="form1" submitdisabledcontrols="true" runat="server"> <asp:button id="btnProcessPayment" onclick="btnProcessPayment_Click" runat="server" onclientclick="javascript :if ( Page_ClientValidate() ) {this.disabled=true; this.value='Please Wait...'};" usesubmitbehavior="false" text="Process Payment" />
I hope this is useful to someone! If you end up using it on one of your sites, please leave a comment!
I've come across this several times. You build a custom control inside of your web_code folder and you can't reference it from your project because you can't figure out what assembly your supposed to reference (as your web code doesn't normally have a set assembly name). I finally figured out how to do this recently.
Normally you're tempted to put something like this:
<%
@ Register Assembly="MyWebComponent" TagPrefix="as" %> When really you need to put something like this:
<%
@ Register Namespace="NSM.WebControls" TagPrefix="as" %> The only trick is that you need to make sure you put your custom class inside of a set Namespace. Normally any class inside of a web project doesn't belong to a specific namespace.
Now we can reference our control:
<as:MyWebComponent ID="MyControl1" runat="server" />