Carl Franklin: Well the question is, will it be buggier with a dynamic C# and a dynamic VB?

Scott Hanselman: Yeah, here's an example. Let's say I wrote some test scripts ... to work on an application and let's say that you're going to write it in an application that has only object, totally dynamic.

Carl Franklin: Right.

Scott Hanselman: And then I'll write it in C# and our test will run against both applications.

Carl Franklin: Yes.

Scott Hanselman: Right? So, the exact same tests we'll do the exact same stuff to a browser, and the App just happens to be written in two different -- totally different languages. As long as all 100 and some odd tests pass, does it really matter? What language it was written in?

Carl Franklin: Okay, now take away the tests.

Scott Hanselman: There you go; if the tests weren't there we can't know.

Carl Franklin: Right. So, the question is if you have a dynamic language that's set up to allow this kind of variant behavior...

Scott Hanselman: Exactly, yeah that's a good point.

Carl Franklin: ...does it put -- does it make it a liability not to use Test-Driven Development?

Scott Hanselman: I think it does, that's a good point. So, doing Dynamic development -- doing development in a dynamic language without a lot of tests could potentially open you up to a lot of weird data typing, conversion type of errors. That's why I think that negative testing is so important.

Carl Franklin: So, then that brings us to the other conclusion, which is if you do not -- if there are more people not doing Test Driven Development, than doing Test Driven Development, are they not going to move to the new dynamic languages and... stay with the old version of .NET.

Scott Hanselman: There were too many nots there; I got confused...

Carl Franklin: In other words, let's say 65% of the development going on does not use Test Driven Development, which -- it's even more than that.

Scott Hanselman: Oh, I am sure it's lots.

Carl Franklin: Right. So, C# 3.0 comes out VB.NET 17.0 whatever it is, comes out and they are both dynamic languages; is that going to keep people from upgrading to the new version, possibly of a new framework, of a new language?

Scott Hanselman: That's a good question. I think that the beat marches on, right? Things continue to move forward. The issue is that when you go to a Microsoft presentation every three or four years they sit down with the Northwind database. They drag a DataGrid over and they say, "Look what I did without writing a single line of code." They've been doing this for 15 years.

Carl Franklin: Sure.

Scott Hanselman: Right? Every few years we go and we see the big DataGrid presentation.

Carl Franklin: Right.

Scott Hanselman: Except this year... we dragged the DataGrid over and it did AJAX, okay? With things like BLinq, B-L-I-N-Q at shrinkster.com/heg, which is the closest thing to Rails on ASP.NET that Microsoft has come out with.

Carl Franklin: Okay.

Scott Hanselman: Let'ssay you basically dynamically generate an entire ASP.NET Website for displaying, creating data, doing all CRUD type data based on a database schema without writing any code at all. So, there is not even any dragging around, I mean they don't even go into - you don't even have to go to Visual Studio. You just say "Do it," and it happens.

Carl Franklin: Wow!

Scott Hanselman: So, I think when people see that we could go and rewrite the Hanselminutes Admin with a tool like this BLinq prototype - once people see that if they don't move, then they don't move forward - then maybe that's not what they wanted, right? Microsoft is trying to make products to make life easier. If Microsoft doesn't do it somebody else will and people will say ooh... I want that.

Carl Franklin: ...I don't know if that's a strong enough argument for me but we'll see.

Scott Hanselman: That's a very good question.

Carl Franklin: Basically, what it means is that people are being forced into Test Driven Development, and will they go? So, it would be interesting to see.

Editor's Note. By "Test-Driven Development", Carl means "Test First" which is the most extreme form of TDD.

Scott Hanselman: Well, let me ask you this, then. Here's a better argument. Were people forced into using Source Control, when Microsoft started giving away Visual SourceSafe? Before anyone in the Windows world was using Source Control - they were using Source Control in the Unix world - but Microsoft people would just zip up their files and say, "Here you go, that's the version for today" and I'll zip it up and put it over on a share.

Carl Franklin: Yeah.

Scott Hanselman: People are going to use Test-Driven Development because,
a.  It's free and,
b.  It works.

Carl Franklin: Once you experience it. So, you think there will be a competitive advantage to being Test-Driven?

Scott Hanselman: Oh yeah. Let me give you an example, there is a shareware developer who had some applications that I installed because... if it exists I've run it and installed on my machine at least once and I went to -- I had some trouble with it so I emailed him, and you know what he said, it's amazing. He says, "Go to the Help about" I am like "Okay, Help about" and he says, "You see a button there that says 'Run tests'". He actually ships his nUnit tests, and in the Help about menu hid an nUnit runner. So, he actually shipped them and I ran his entire test suite on my machine, which let him see if the environment that I was running on would pass his tests and one of the tests didn't pass because he had made an assumption about a path.

Carl Franklin: Neat.

Scott Hanselman: What a brilliant way to do production time debugging.

Carl Franklin: There's no doubt about it that when you reach the end of a life cycle of an application built with Test-Driven Development you've got a superior product. I guess the people on the other side of the camp -- and I am not taking a position either way-- I am saying the people on the other side of the camp say, "Well, if you live in an ivory tower world, where there's an infinite amount of time and money to develop, great, but for the rest of the real world people out here we're trying to build apps as fast as we can, as most stable as we possibly can."

Scott Hanselman: Right. Well, let me give you one more argument, and then we'll do a couple of links and move on.

Carl Franklin: Okay.

Scott Hanselman: So, you can express the business requirement in a simple test, right? The requirement is they must be able to read a record, change it, and save it and these conditions will be met. You can say that in English - or any language for that matter. You can say it in prose and write it in a Word document. But as I've said before, a Word document doesn't have any teeth, right? Word documents don't break builds. Exceptions stop applications, but Word documents don't actually do anything; but if I can write a test in a very simple straightforward way that says, "This is my intent", right? We spent so much writing code to express our intent. But, we're expressing that intent to the computer, right? But the computer is not the customer here; the customer is whoever has hired me to write this application.

Carl Franklin: Sure.

Scott Hanselman: So, my tests are the best description in computer language of what that person's intent is. So, if you look at Test-Driven Development as a way of translating that person's intent into something the computer understands and then also proving that the requirement is met. You can look at all of those green bars that light up in nUnit telling you that your application works well. That's basically saying, "My requirement was met for this application." And if you look at it that way, you'll spend less time writing specs because specs aren't useful, right? Specs can't test my application, only tests can. So, that might be a better argument.

Carl Franklin: Okay.

Scott Hanselman: One other thing I wanted to mention was that, we are talking about Rails -- what it was like to have Rails, and/or ActiveRecord on Windows.

Carl Franklin: Right.

Scott Hanselman: There's something worth checking out called the Castle Project. You can take a look at shrinkster.com/hen. A Castle is a set of tools-- you can work with them together or you can use them independently-- that let's you... integrate your applications [better] and the really interesting ones are MonoRail. MonoRail - they used to call it Castle on Rails - is basically Rails for ASP.NET. It's a different style, it's more of a Model-View-Controller, what they call MVC, or action-packed way of doing things. There is an interesting explanation about how it works, why you might want to do it, why it would be useful, if you like Rails you might check that out. But the most interesting thing I think is a layer that sits on top of nHibernate, right? nHibernate is the Object Relational Mapper, that let's you take objects and map them with XML or relationship files into the database. This is a version of ActiveRecord and the ActiveRecord pattern for .NET. It's built on top of NHybernate but it frees you of all that XML tediousness.

Carl Franklin: All right, so a couple more -- we've got time for a couple of more links.

Scott Hanselman: Sure, yeah. If you want to check out Blinq, which is B-L-I-N-Q, there's a really good tutorial at Arstechnica at shrinkster.com/hej and then FTPOnline has a great tutorial from last month before last on how to use Blinq at shrinkster.com/hek and again you can download Blinq at shrinkster.com/heg and then do check out the Castle project-- It's a really interesting way to think about things. It's different from ASP.NET. It's not how you are used to doing Web applications and that might be a good thing-- at shrinkster.com/hen.

You can listen to this entire show at http://shrinkster.com/hxg