I just posted the files from my Fairfield, CT CodeCamp presentation. Thanks to Mark Freedman and company for having me.
I’d also like to address a couple of questions I was asked, one during the presentation and one a couple of hours later.
1. Does the C# compiler duplicate field initializer code?
Yes, it does; but that’s not a problem. I added two overloads of the Constructors.ComplexInitialization.ComplexInitializationBase constructor to illustrate. The two overloads have the signatures (string) and (). When you chain them together: (string, string) => (string) => (), only the no-parameter constructor (), gets the field initialization logic. If you unchain them so both the (string) constructor and the () call the base constructor (System.object.ctor), then both get the field initialization logic. Apparently, the C# compiler only adds field initialization logic to constructors which directly call a base constructor, guaranteeing that while the code gets duplicated it only ever runs once for any given object.
2. Do object initializers work with properties
Yes. They work with both public properties and fields.
Later!
Good attendees learn from the speaker; this week I was reminded that good speakers learn from their audience. The NJDOTNet (http://www.njdotnet.net/) group was fun (My thanks to Jess Chadwick for the invite!), a lot of sharp, involved people (and one wise-aleck to keep things interesting).
NJDOTNet’s feedback shows I need to clarify a number of points. They are the relationship between the iterative development process and test case selection, the recommended number of asserts per test, and the relationship between BDD and analysis.
Iterative development (Red, Green, Refactor) is a process for developing code; it has no bearing on the choice of test cases. Red means write a failing test, ensuring the test can catch failures, that is test your test. Green means make the test pass, as ugly as you need to be. Refactor means clean up, so you can move on to the next feature. As a participant pointed out, it is possible to regress the system such that a test always passes, still I think it more likely to initially write a test which can never fail.
The TDD community recommends one assert per test to simplify debugging. Their goal is to fix a failing test in a single code, test cycle. If a test has multiple asserts then more than one assert can be broken by a given set of code changes. Since failed asserts throw an exception, a failed assert stops the test, preventing any other asserts from being evaluated. This can result in fixing one failed assert, only to find another failed assert in the same test, preventing the test from passing.
Personally, I haven’t paid too much attention to my assert count and am moreover in full agreement with the TDD community that each test must verify exactly one behavior. When I do use multiple asserts in my tests, I rely on careful choice of assertion failure messages to facilitate debugging. I’m not that concerned if I need multiple code/test cycles to fix a failing test, so long as failed asserts have informative messages. As they say, your mileage may vary.
BDD blurs the line between analysis and coding. An early discovery of the inventors of BDD, was that they were using the language of business analysts to name their tests, a very good thing! http://dannorth.net/introducing-bdd At the very least, BDD can replaced low-level design documentation with executable specifications, which are much more likely to be up to date.
Till next time.
I’ve just been reviewing my TDD/BDD presentation. I’m giving it at http://www.njdotnet.net/ on Thursday May 14 at 6PM. The state of the art has advanced considerably since last year when I first put the presentation together. Of particular interest are the new mocking framework, moq(download at: http://code.google.com/p/moq/wiki/QuickStart) - and the SpecUnit extensions (download at: http://code.google.com/p/specunit-net/, more info: http://www.code-magazine.com/article.aspx?quickid=0805061&page=4).
Moq flattens the learning curve for using mocks. It hides record and playback providing modeless mocks. This allows developers to focus on using the mocks, not on arcane mock configuration rules, like when expectations can be set.
SpecUnit moves BDD terminology and structure into the comfortable confines of the NUnit world. The extensions and tools added by SpecUnit facilitate implementing executable specifications and add to their communication value for developers and stakeholders alike.
I’ve revised the section of my presentation on mocking to use the Moq framework and the new “test double” terminology. Before I give the presentation again, I’ll revise it to use SpecUnit, and take advantage of the context-observation structure, so that instead of showing an NUnit test window, I can show a customer-ready report.
That’s it for now.
Last weeks’ Richmond Code Camp was excellent! After giving my presentation I hung out in the Open Spaces area where the topics ranged from a custom framework that separates concerns in ASP.Net to whether or not Behavior-Driven Development is distinct from Test-Driven Development. The after-party featured Alan Stevens performing on his guitar; we left before he did “Code Monkey”.
I ended up speaking to small audience in a large auditorium. The tips I got from the other speakers afterwards (get down with audience, get them asking questions, etc.) will help next time. Thanks to ken.taylor for his kind words. Here as promised are the presentation files.
Alan Stevens was provocative and interesting. As leader of the (almost) Open Space, aka Community Courtyard, aka, goodness by any other name, Alan forced participants to articulate and defend their positions while reexamining the familiar. I look forward to participating in future events. In fact, I’m even considering CodeStock so I can be part of the real Open Space he’ll be facilitating. Not that I’m a fanboy or anything, but I was impressed. Speaking of impressive, he showed an ASP.Net framework which achieves good separation of concerns. Hopefully, he will remember to post the files for his framework; it looked like an excellent way to refactor existing ASP.Net code for unit-testing.
The after-party was fun, good food (paid courtesy of the organizers, Thanks!), good friends (both those I know, and those I’d just met) and some very funny songs supplied by Alan. I was a bit worried his first song would get us thrown out and was too busy laughing to care.
That’s all for now, later!
I’ll be presenting at the Richmond VA CodeCamp this weekend.
Session: Advanced Techniques for Everyday Development - Building a basic text messaging system using Behavior Driven Development with Mock Objects.
Presentation Level: Intermediate
Presentation Abstract: Confused by the new techniques coming in from the Alt.Net crowd? Don't know the difference between a mock and a fake and not sure why you should care? We'll start with an overview of Test-Driven Development and its successor, Behavior-Driven development. You'll see some of the basic tools in action (NUnit, TestDriven.Net). We'll use a state diagram to break down a complex business problem and see how to convert that into an executable specification using Behavior-Driven Development and Mock objects (NMock2). We'll finish by looking at an implementation of that specification.
I’ll post my slides and files next week. Hope to see you there!
Hi, and welcome to my blog. My name is Edwin Ames, but you can call me Ned. I’m a software developer with 10+ years experience. You will frequently find me speaking at DotNet Code Camps and User Groups. This blog is my way of keeping you up to date on my speaking engagements and posting related files. I’ll also share my thoughts on technical topics that might interest you.