Attention: We are retiring the ASP.NET Community Blogs. Learn more >

MSDN Webcast on NUnitAsp was a blast! Download link and Q&A summary

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.

 

 

5 Comments

  • How do you test Session, Application variables, ViewState and public properties that in a webform.

  • This is not really possible with NUnitAsp. NUnitAsp operates at the HTML level - it only sees the output of your page in the same way that a browser would. Therefore it does not have access to Session, Application or Public Properties. It does see the viewstate if you are keeping it in the form (the default) however I have never had a need to test the values in the Base64 encoded string.



    Rather think about testing your ASP.NET page at the interaction level: what should happen when I click this button, etc. This is more the realm of NUnitAsp.



    Hope that helps.

  • Thanks for the link - interesting stuff.



    However, this is still not NUnitAsp doing the testing. Remember that NUnitAsp operates in a different process to your ASP.NET pages - it does not have access to Session, Cookies and any other web specific object. Sure ... you can test your web code using the technique in your link but that is a different type of testing entirely and actually is using NUnit not NUnitAsp. I would also question the idea in the link of making your production code behave in a different manner for testing - this is certainly not the best approach.



    Thanks for your feedback. (and the link)

  • Have you used NUNITAsp with .Net version 2.0 yet?



  • Not yet. We are so busy consulting with VS.NET 2003 - it is hard to look at the new stuff.



    I am hoping that the HTML output from the ASP.NET webcontrols hasn't changed too much and NUnitAsp will just work.



    I will be presenting at the Pittsburgh .NET User Group in November on NUnitAsp and will be looking at 2.0 given the launch date is 2 days before the event!

Comments have been disabled for this content.