I follow @unclebobmartin on twitter and was also getting caught up with his blog posts and have been enjoying his rant-like video posts. I particularly liked this one about Architecture Deference and even tweeted saying so. I found it to be a good pre-cursor to this post on Screaming Architecture which I'm sure came partly as a result of the first.
I've been dealing with issues in some of our apps and haven't been able to put my finger on where they stem from and these posts really seemed to highlight for me what it likely was in the approach that caused these issues. From the running of tests taking too long to too much focus on the aspects that don't really matter and should be deferred, I think I know where many of the issues lie. The only problem now is figuring out how to fix it once it's been done... or is it too late? Would it be too much to decouple the model, or the architecture, from the frameworks and tools to make it not worth the effort? Do we just say lesson learned and take a more correct approach the next time around?
How tired am I? Do I just want to go to sleep in the bed that's made or do I remake it? Can it be remade?
Showing posts with label Unit Test. Show all posts
Showing posts with label Unit Test. Show all posts
Friday, October 7, 2011
Wednesday, March 25, 2009
TDD in MVC applications
When developing a web application using MVC there are some components of the application that are not easily tested and can't be tested using automated unit tests. Since automated unit tests are the TDD bread and butter it follows that you can't use Test Driven Development for every aspect of your application. Our team has mentioned that it is difficult to know when to use TDD so I'm hoping to provide some guidance to help in this area. Any comments or suggestions about other methods are welcome.
Libraries: "That code should be in the Model!"
I think it's pretty simple really. Basically anything that will be used as a library function should have a unit test written for it and anything that should have a unit test written could be developed using TDD. In MVC, you would use TDD to develop Model code. If there is any code in the controller that contains some business logic that could be pulled out and made into a library function then that code should be in the model.
Any other aspect of the application would need to be tested using acceptance testing methods.
Libraries: "That code should be in the Model!"
I think it's pretty simple really. Basically anything that will be used as a library function should have a unit test written for it and anything that should have a unit test written could be developed using TDD. In MVC, you would use TDD to develop Model code. If there is any code in the controller that contains some business logic that could be pulled out and made into a library function then that code should be in the model.
Any other aspect of the application would need to be tested using acceptance testing methods.
Subscribe to:
Posts (Atom)