Unit tests (lack of), SpringAir, and aspx controller

[scottnelsonsmith]

When I look at the code in the aspx.cs code-behinds, I marvel at how much logic has successfully been moved into other, more testable, classes in SpringAir.core. Congratulations!!! :D

However, in the SpringAir code-behinds, I find some code in regions marked Controller Methods (most notably in TripForm.aspx.cs).

My question is: why isn't this controller code moved into a simple class outside of the code behind where it can be tested? I can think of the following reasons:

:arrow: It is no problem to test these controller methods in the code-behind directly. Simply directly create an instance of the code behind class using the empty constructor in your unit test and test away!. :arrow: The author ran out of time and didn't place the code in separate controller classes. :arrow: The author didn't think the code was complex enough to warrant unit testing.

So, I tried the first alternative above and it worked fine.

Still, does anyone have any ideas on why the mothods in region controller are not moved to another class? Thanks in advance!

Scott

[Aleks Seovic]

Good question :)

The way I see it is that unit testing is not a deciding factor in this case when choosing whether to extract controller logic from the code-behind file or not -- as you pointed out, you can simply create an instance of the code-behind class and test away.

The real reason I left it in there instead of moving it to a separate class is that controller logic in TripForm is simple enough that leaving it in the code behind actually results in a simpler and more understandable system overall than if it was moved to a separate controller class, especially for Spring.NET newbies with ASP.NET background.

Admittedly, there is a gray line in play here when deciding whether to separate it or not. My rule of thumb is that if the controller code is more than two or three methods and/or more than a single screen of code, it should probably be extracted into a separate class. Another reason to extract it would be reuse, so if you have a controller logic that can be used by multiple pages, you should extract it.

I'm interested to hear what everyone else thinks. To a certain extent, this decision is also a matter of personal preference, and I would like to know what Spring.NET users see as a best practice and how are you actually developing your applications using Spring.Web, with or without separate controller class.

- Aleks

P.S. Another reason why TripForm code is the way it is right now is so I can demonstrate controller extraction refactoring during Spring.NET presentations :)

[scottnelsonsmith]

Aleks,

Thanks for your thoughtful reply. I realize that this is a "software metaphysics" question, and so I was just curious.

My point of view is close enough to yours. I like that you encapsulated the "controller" code into a "controller" region; I'll remember that technique.

Scott