http://codebetter.com/blogs/jeffrey.palermo/archive/2006/03/28/141920.aspx is one response to the show.
Surprisingly enough I agree with alot of the commentary (even though I am TDD fan) and I found him to actually be supporting TDD with a very subtle change that I myself often use.
I often find myself taking a slightly different TDD path than many; more similar to what Rocky describes. I often will create a stub of an object prior to writing my tests for the object, I find myself doing this even more so for interfaces. I will create an interface .. I will then write all of my tests for the interface. After this I will implement my concrete implementations of my interface and test them using my tests. This is not an accepted practice with TDD but I fnd that it works extremely well for me and I am still maintaining a contract first design methodology.
I think what is important here is that we are discussing a very subtle difference in the process and the ability to use tools that are provided to allow us to work in a more expedient fashion. I definately lose some level of thought process in the signature of my method as I already have it when I am creating my tests but it is quite rare that I find myself going back and changing this due to my tests, perhaps this is from experience and the method will not work as well for others but it works for me and thats what is important.
I agree with the post above on the “test harness“ case and that these items should in fact be unit tests as the framework will manage them for you.
In listenning to his discussions on CSLA (validation) he came accross some interesting concepts. He discusses the last version of CSLA and the way that it handled error handling. In setters one would assert whether a rule was broken or not. This can in general cause some huge issues as we often times want differring validations at differring states and can lead to lots of problems. He says in the new version that he uses delegates in what sounds oddly like a specification pattern (in fact it sounds exactly like the specification pattern except that it uses delegates returning a bool as opposed to typed objects with a method that returns a bool). I would love to hear more as to why the delegate route was taken as opposed to the specification route perhaps there is significant performance difference but at first glance it would seem that the specification pattern offers an easier metadata application in order to allow for run-time configuration of specifications.
Carl Franklin also had made some commentary that “events don't exist in remoting” ... Maybe I am using a different version remoting but this comment really put me at a loss for words since the remoting versions I have had do in fact support events *scratches head* maybe he had it confused with webservices?