Yesterday's MSDN Webcast on Test Driven Development with NUnitAsp was a lot of fun! Attendance peaked at around 130 people during the session and yes, some of them even stayed the whole way through! :-) A big thank you to my fellow Thycotic consultant, Jeff Schoolcraft, who fielded attendee questions via chat during the entire session spreading TDD and our Thycotic approach.
If you missed the live webcast, you can still watch the recorded session.
(Look for another post soon describing my impressions of speaking on a webcast versus a live audience.)
Here is a summary of the attendee questions with Jeff's answers:
Reza: When should unit tests should be written before, middle or after developement?
Answered: Jonathan will get to this, but theory is your write a test to demonstrate expected functionality before you implement that functionality. So the answer is before development, but before each piece. There is a school of thought that thinks some people can write all the tests before any development is started and some lower class developer "code slaves" can come back and make all the tests pass and you'll have a working system. We (Thycotic Software) don't agree with this school of thought. We write tests before implementing functionality as described in flow in a few slides.
David: Another Benefit of TDD (and the other side of "refactoring needs TDD safetynet") is TDD allows refactoring/tidying up code!
Answered: David this is a great point. Without being able to run your entire test suite after some refactoring to see what's broken, or more importantly when everything is back to green, refactoring would be suicide. The simplest refactoring, renaming, probably has the broadest impact to your codebase, I can't imagine renaming (or refactoring) without a test suite.
Asit: is nunitasp only for c# or will it work with vb.net?
Answered: NUnitAsp is just an assembly, it'll work with all .NET languages, so yes it will work with VB.NET. You'll notice some syntactic differences with how you attribute your code, and such.
salam: In Nunit we provide a test project for testing another project, so the first demo, what was the idea behind it, what was the test for?
Answered: You're not seeing the solution explorer, but we'll cover this in best practices. Our model is very similar to yours, we'll have a test project for every functional project in our "solution" in VS.NET speak. Similarly we'll have parallel tests for all objects (Business.Foo.cs and UnitTests.Business.FooTests.cs). We do the same with NUnitAsp, but we model on the TextFixture per ASPX Page level.
Raymond Lewallen: Can you use NUnit.Extensions.* along with MbUnit.Framework instead of Nunit.Framework?
Answered: More simply the question is, can I use NUnitAsp with MbUnit. The answer is yes. There are some examples here: http://weblogs.asp.net/astopford/archive/2004/11/17/258823.aspx (NUnitForms and NUnitAsp are covered).
David: Do you see existing applications getting unit tests bolted-on or just for new/rewrite applications?
Answered: Dealing with existing applications presents it's own set of .... joys. We've typically approached this as writing tests for any changes or enhancements we make to the code base. For the most part we find it impractical (money and time) to go back and retrofit all the tests to existing code.
Chris: You *would* want 25,000 rows for performance testing, but that's a different topic altogether!
Answered: Yes, performance is a completely seperate topic all together. Generally we don't code for performance, but that isn't saying we implement code to perform poorly. Where it makes sense we'll give the approach that might be more performant the nod if all other things are equal, but we're testing functionality (most of the time) not performance.
Rahi: What was the Database scripter tool?
Answered: It's the Thycotic.DatabaseScripter, here is the link: http://thycotic.com/dotnet_dbscripter.html
woaksie: Why wouldn't you use backup and restore for database resetting?
Answered: The simplest answer is it's just too cumbersome for what we're trying to accomplish. A foundation of TDD is that you're always starting from a known state. When dealing with a database that means that every bit of test data is the same, each and every time a test is run. So we're resetting test data on every single Test. When you're running a test suite with thousands of tests you're talking thousands of backups and restores, it just get very impractical.
Charles: If your application heavily leverages client-side jscript, it seems NUnitAsp would not be able to test this. Is that correct?
Answered: NUnitAsp operates at the HTML and HTTP level. It doesn't execute or interpret Javascript. There is a great framework for testing Javascript libraries called JSUnit: http://sourceforge.net/projects/jsunit/
Thycotic's Remote Scripting client implementation uses JSUnit to verify its functionality.