2 week review

Normally this should have been a number of posts but I've been a little lazy on the writing front and busy on the "doing" front. I'll try to do better.

but first a message from our sponsors

So I can stop with the oblique references to "a system here at work" I'll call a spade a spade and now refer to my MVC application as iDEV because, well, that's what it's named (not my first choice in names but that's where we're at). And I'll stop with "it does stuff" because no one is reading this save myself and even if they were, they're not about to run off and steal all my ideas and build "the next big thing." What I've done has been done before and done better. Moreover, if you're stealing from me you're stealing twice.

there is *way* more to this testing thing than i thought

My last post was more prescient than I would have thought possible. Writing tests is...actually it's sort of interesting. There's a lot to do to be sure (more on that later), but the whole notion of thinking about what it is you want, writing some tests, and then implementing until they pass is fairly gratifying. At least in the sense that something didn't work and then does because, see, I have all these little tests that tell me so. It's also a metric fuck-ton of more work to do.

When I started with Rails I more or less skipped the whole testing framework. Wish that I hadn't now, but at the time it was way more fun to whip out features. So when I set out to learn ASP.NET MVC/redesign iDEV I was committed, to the extent possible to do it the right way - testing, testable patterns, and layers man, layers! What I didn't have an appreciation for, at least w/r/t to writing unit test vs. integration tests, is how much goes into making that possible. Especially all the things I have to learn. To be able to test these things in isolation means learning testable patterns, understanding how and what should be tested, and then understanding when to stub/fake things and when to use a mocking framework (in my case Moq).

Its been challenging to be sure. The only thing that's sort of driving me nuts is the the repetitive nature of the tests I'm writing. Given your typical Create action on a controller - I have to write a test to verify the view isn't null, returns the right model type, redisplays on an invalid model, and saves and redirects on a valid model. And that's just for one action in one controller (and I'm probably not writing enough tests there as it is). I still have to write essentially the same code for each create action in each controller - and I have a lot of controllers.

So I could make the argument that I know that I've implemented the controller actions correctly (since they're all mostly the same) and can now skip all those tests. Which would defeat the whole notion of writing tests in the first place. So I'll keep at it. Lot of work though. Especially when you think about how much visible stuff you could be implementing if you weren't writing all those tests. Best not to think too much.

the new hotness

It's always fun learning something new. No matter how trivial the item, it's something new that you didn't know before and now you do. But there's also the frustration. The "why the fuck won't this work?" - I'm following the example to the letter...no wait, I forgot that line. There, now it works. Frustration and reward - the lifecycle of the developer.

Trying to do things "the right way" on this project also means new things beyond just the framework. Things like Moq and StructureMap for dependency injection. Which, while it is incredibly cool and I understand conceptually how it works, I still don't entirely understand. Even spent a few days trying to make it work with version 2.5. All the code samples I could find were for prior versions with deprecated methods. Thank god for this article. Frustration and reward.

So to sum up, learning ASP.NET MVC means learning:

• The framework of course
• Moq
• StructureMap
• TDD/BDD
• Linq to SQL
• Testable patterns

It can be a little much sometimes.

things from my dome-piece (b/c thoughts might be giving me too much credit)

So a while ago I had this post outline talking about the differences between Rails and ASP.NET MVC. I think it's worth going over. Rails was dead easy - ruby script/generate Scaffold Product name:string and you had a model, controllers, and views for basic CRUD operations on a Product. There is way more plumbing that goes into ASP.NET MVC to accomplish the same thing b/c it [ASP.NET MVC] lets you choose how you implement your models. In Rails there was only the way. Play by those rules and your life rocks. Validation with a few lines, relationships with one more. Pretty cool indeed. I mean you still had to write the tests but you can't win them all.

So Rails development was fast to say the least. ASP.NET MVC offers some scaffolding features similar to Rails but not quite all of them. On the other hand, b/c Rails offerered only "the way" the only thing you really learned was Rails - or at least the Rails way. With ASP.NET MVC you have to make decisions, decisions that aren't necessarily well informed b/c, remember, you haven't done this before. And b/c there are decisions and alternate ways of doing things there is what I'll call tangential learning - things that are applicable outside of the current problem domain. Things that will serve you as a developer when ASP.NET MVC and the current project are long forgotten.

Frustration and reward.