For some background on who's using mock objects and why, check out Martin Fowler's updated Mocks Aren't Stubs. There are some clear advantages to both the "classical" and "mockist" model. I appreciated his eloquent comparison between the two, and it seems to fairly represent both mindsets. I think I have a better understanding of when to turn to mock objects. And there are some interesting corollaries to my own work in managing states and expectations in state-based tests, which I someday hope I can write down. (I'm just trying to get back in the habit of writing at all first...)

But mostly I'm writing to say "Yes!" and "Thank you!" and that I very much agree with his wrapup: I really like the fact that while writing the test you focus on the result of the behavior, not how it's done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations.

Of course, I suppose I'm more focused on acceptance tests at the moment, so looking under the hood feels more wrong than usual. I'll grant that there's a real place for mocking in unit testing. I just think it's smaller than some do, and I'm oddly heartened that it's not just me. :)

I just googled for "ecmascript java rhino jscript.net actionscript flash "virtual machine"" and the only thing that it found was the JavaScript entry on wikipedia.

Maybe this is a fever dream from the flu I'm just now shaking off. I really am taken by the idea of a standard, established, independent language, EcmaScript v3+, which can work unmodified on the Java virtual machine (standard as of version 6), the Flash/Flex virtual machine (ActionScript), and the .NET CLR (JScript.Net).

(And it's JavaScript? Unbelievable. I'm not a fan of JavaScript, although that really has a lot more to do with my dislike of HTML. Yes, HTML has accomplished amazing things, but it's so inelegant. Besides, JavaScript in a browser is subject to the whims of the browser. I don't know about Rhino, but Flash and JScript are both good solid implementations of this.)

EcmaScript seems to be all things to all platforms. It's OO, if you like that. Or functional, if you prefer. It's dynamic. It's static. It's got closures. Reflection is probably VM-specific. It runs in every browser, on any Linux server, on any Windows or Mac front end. Heck, it'll run in either an Oracle or a Microsoft SQL database.

Business logic in EcmaScript, isolated from language-specific libraries, with portable unit tests, and serialized. Now, that is some DRY, mobile code. I can now move behavior across the wire, across different virtual machines, as easily as data.

...

It is also, I should note, the red-headed bastard stepchild of .NET, with no decent editor available. Managing references is already hard in JScript. Managing the same code that to be copied around into different projects and actually requiring a different compiler for each different components... that's a little different. But I've done a lot of fancy build scripting lately and I think these problems could be overcome.

...

So, I once posted on Bob Martin's message board that dynamic languages would really take off as soon as there were really good IDEs. I really like debuggers, IntelliSense, and refactoring. Ah, well. I may find out if he was write that good unit tests can replace debuggers.

...

So, next question: What does Ruby really have on EcmaScript? EcmaScript V3, I mean; the older ones that don't support classes just don't count. Probably a slightly cleaner syntax. But is it significantly limiting? If only there were a Rails.NET, I could really compare apples & apples.

Python, of course, I could compare more easily to IronPython.

Very intriguing.

Does Quality always get the respect it deserves as one of the key tradeoffs of project management? Here's an interesting article from InfoQ, a reflection on a talk of Ken Schwaber's, "Sacrificing Quality should be an Executive Management Decision", that I found through Carnival of the Agilists. I think Ken Schwaber's ultimate point is something like this:

Traditional project management focuses on tradeoffs involving time, scope, and cost. Quality is not as explicitly managed. Therefore, quality can be sacrificed at any time for any reason by any individual on the development team.

We now have reason to believe that high quality work actually gets things done faster. Less rework, etc. So quality should be re-emphasized, and the decision to cut corners should only be made strategically by the product owner and never by the development team.

The response is interesting. A lot of people said (kinda rudely) how stupid it was to assume all projects require high quality, and how stupid it was to push everything to the CEO. Well, they're half right. The point is, it's management's call. How high in management, well, that depends on the project. Basically, some people were distracted by the word "CEO", and I'm not sure if that was Ken Schwaber's or the poster's wording.

Anyway, the response illustrates exactly the response many people will have to the idea. I think to those of us that have studied these issues the choice is pretty obvious. So, I have two questions:

Product owners and managers need to ask for high quality work, instead of just getting the job done. Historically they always asked for the opposite. They will also need to fund a test for high quality work. I think actual code reviews may be required. (I don't think a set of passing unit tests is quite sufficient here, because the model itself is one thing that should be reviewed.)

How do we educate the product owners and managers to be able to make these decisions? I agree with Ken Schwaber that these are the people to who should make these decisions. Though I'm not sure they'll buy the "Quality Costs Less" principles easily. I've learned that "Technical Debt" was an astonishingly easy concept to introduce, perhaps because people were already familiar with the idea and finding a name for it made communication easier. Perhaps I can rephrase it in those terms.

There has been a lot of discussion about post-Agile, pliant, ex-Agile, etc. It's kind of interesting to see how quickly people jump off of a bandwagon. I shouldn't bitch; most of these people were probably in fact never quite on the bandwagon. I still think this is a great philosophy... but somehow I never quite managed to consistently sit down and write tests first. But I couldn't put my finger on the reason...

Wow. This one really caught my eye. Fred Brooks of Mythical Man-Month fame, whose wisdom on software is still applicable decades later, wrote an article in 1987 that damn near predicted the Agile movement. This isn't Agile in the name-brand TDD sense, but a more general recognition that the most effective way to develop complex software is to iteratively "grow" it. Build one to throw away becomes a "spike". I can definitely see the evolution of the ideas a bit more clearly now.

Software Engineering Explained, as posted by Andy Hunt.

Bruce Eckel points out a key distinction between standards that work and standards that don't. He quotes an article about CORBA's decline and reduced it to the wonderfully clean and understandable:

A standards body should formalize existing practice, rather than inventing new practice without experience.

Yeah, Web Services fits into that mold, too. But maybe not quite as badly as CORBA... at least Microsoft and IBM and Sun are all at the same table on this one.

Well, okay, it's not all about him, but that was the part of this CodeProject article that I found the most compelling. I ran across this in a discussion over at Joel's. I'd like to credit "RandomPunter" for the link, but I'm not sure if that accomplishes much.

Recap: We all know that C# and VB.NET are effectively tied with each other, feature for feature. If you think late binding, implicit casts, and implicit event management are always a good thing, you tend to like VB. If you think that early binding to interfaces, explicit casts and explicit event management are always a good thing, you tend to like C#. So, how to choose, other than arbitrarily?

Microsoft is talking a lot about its forthcoming LinQ for SQL (not DLinQ!) and ADO.NET Entity Framework technology and it really looks pretty sharp. (Despite the confusion over there being two mapping technologies.)

But I have a reservation. Here's a quote from the Entity Framework doc:

No plumbing. The code is very database intensive, yet there are no database connection objects, no external language such as SQL for query formulation, no parameter binding, no configuration embedded in code. In this sense, you could say this code is “pure business logic”.

(No time to grab an image just now. Go to the doc to see the code it's talking about, but if you've seen DLinQ samples before, you've seen it.)

So, is that a good thing? Pure business logic that generates the appropriate SQL and parameter binding and config logic? Or is that an unfortunate merging of domain concerns with implementation concerns?

There seems to be a lot of talk about the shape of Agile this week.

Cedric Beust thinks Agile is just plain wrong.

Bob Martin responds.

And a few other posts referenced it.

This one predates this argument, but I think it's related. I can't disagree with the idea that different contexts call for different solutions. Personally, I think Agile approaches have a lot to recommend them in the contexts I work in. But I can't deny that there is a little bit of religious fervor out there. These are some good rules of thumb to keep things in perspective. It's not a silver bullet, folks, just another improvement to build on.