+972 52-548-6969
Tools vs. Design
time to read 1 min | 69 words
Just read this, Eli Lopian talks about how you can use Type Mock in order to avoid separating responsabilities:
I am going to show you just how we can manage to unit test a Simple Dialog without separating concerns
I have a problem with this statement. Why would I want to avoid separating concerns? The Single Responsability Principal & Separation of Concerns are critical to building maintainable systems.
Comments
The only possible explanation would be legacy code you can't change. But then, perhaps a quick refactor of the code, followed by your unit tests is in order.
The more time you put into a unit test to make it work around limitations in your design, the more likely you are to introduce new and wonderful bugs, probably in your unit tests.
I think this falls into the same bracket as unit testing private methods... it implies something is rotten in the state of Denmark!
Oren, you should read the end of the sentence that you are quoting
"and overcome the forbidden decree that GUI is hard to test"
This is the reason to avoid separating concerns.
Our differences are not Tools vs Design but Design vs. Process
http://www.elilopian.com/2007/06/11/design-vs-process/
I've worked with plenty of people that argue that separation of concerns and single responsibility increase complexity and make code too "abstract," so they probably enjoyed the article :P
I have read that, but I don't agree with you on this.
It is not that GUI is hard to test, (and it is, even with TypeMock, because you have complex user interactions), it is the permise that you shouldn't design for SRP & SoC that bother me.
Comment preview