Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Links for this morning

I don’t normally do link posts, but sitting in the JetBlue terminal at JFK at 6:30 in the morning isn’t conducive to writing original content.

 

  • Raganwald talks about Another problem with problems with design patterns.  In a way, it continues my argument that we need language improvements in .Net as much or more than more libraries.  A more expressive language with more powerful idioms equals less code.  Less code all the time with a better language versus less code if the libraries that Microsoft added are usable in your exact situation.  Hmm. 
  • From the guys at Mock Objects comes Listen to the tests.  Several good posts actually.  We’ve had some conversations on the altdotnet list about difficulty in unit testing being a code smell.  I need to pay more attention to this.  I’m seeing this popup far too often in my MVP implementations.
  • From Nat Pryce, Allowing tests to drive development.  Opening up the TypeMock argument once again with this quote:

“Break dependencies in unit tests only with techniques that I would be willing to use in the production code.”

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://colinjack.blogspot.com/ Colin Jack

    > I am not suggesting that you need to test the implementation details of a class. Of course, we don’t want
    > to test our implementation details, only the required interface for our consumers. The implementation
    > details, which may well be private methods, will emerge as we refactor and disappear as we refactor. So > I do not want to test those because that creates resistance to change.

    Yeah definitely, testing private methods is to me never useful. However sometimes you extract a class instead of a method you extract a class. I’d certainly keep that class internal initially, until production code wanted to use it, it sounds like you might make it public?

    > My tests are a consumer of a contract and my tests do not want to consume the implementation of those
    > contract, just the services described by the contract.

    Sure, mine too. But if you start making methods/classes public just to see them from your tests then you are changing the contract and in many cases I would say not in a way that I’d desire.

    > However the usual drivers for InternalsVisible etc. we see is when someone realizes that there is a part
    > of the state that their test needs to check which has no other consumers than the test itself. In that case I
    > am suggesting that there may be a need for promotion to a public contract, because the tests tell us it is > something that consumers need to depend on.

    Now I understand, normally we see it when a class is an implementation detail but we want to test directly against it. I agree with you about the other situation, and as long as its up to you to decide whether to promote it to the public contract then I have no problem with it.

  • Ian Cooper

    @Colin

    Ah I think I see the tangent.

    I am not suggesting that you need to test the implementation details of a class. Of course, we don’t want to test our implementation details, only the required interface for our consumers. The implementation details, which may well be private methods, will emerge as we refactor and disappear as we refactor. So I do not want to test those because that creates resistance to change.

    My tests are a consumer of a contract and my tests do not want to consume the implementation of those contract, just the services described by the contract.

    However the usual drivers for InternalsVisible etc. we see is when someone realizes that there is a part of the state that their test needs to check which has no other consumers than the test itself. In that case I am suggesting that there may be a need for promotion to a public contract, because the tests tell us it is something that consumers need to depend on.

  • http://colinjack.blogspot.com Colin Jack

    “Yes I was making a separate point which is to question why you want to hide information that your tests needs by making it private, just because no one other than the test needs it. If I hide it them I do not want you to depend upon it and reserve the right to change it. But if I expose to tests via InternalsVisibleTo, something now depends upon it and so will be impacted when I chose to change it. ”

    Sure but I’m in control of my tests, they’re in the same solution and I also am careful about how coupled they become to the implementation. Keeping members internal/private helps, as does thinking if you want to test the piece of functionality through the nearest public interface to it.

    “Tests drive needs. So if my tests needs to know about that property of the object or call that method, I would suggest that the test is telling you that it should be public.”

    I’d suggest that if your production code doesn’t, and especially if you have 2+ users, then the production code is telling you far more strongly what is needed. Tests sometimes need to see things that your production code will never need to see.

    Personally I think my tests tell me a lot about how to design my public interface.

    “If you want to hide it from other consumers, because you think that they should not depend on it use separate interfaces to distinguish between the two roles that we have, client of production code and client of test code.”

    But then I’d be complicating my design to allow testing and I’m not sure how this is better than using InternalsVisibleTo?

    “I’m suggesting that the needs of test code are first order needs the same as production code.”

    The needs of test code are quite often quite different to those of production code though, and I’d prefer to wait until there is a production need before making something public (especially pure implementation details). To be honest we write in house software so that may influence my thinking a lot (because we can make something public at any time), plus I just can’t think of many situations where having made everything public would have helped.

    I’m guessing we work very differently though, I find TDD most useful against public interfaces to the classes. Implementation details to me stay hidden so whilst I sometimes tests against internal classes I don’t find TDD is quite so important there not least as I already have a concrete user of the implementation detail class (especially if I used extract class to create it). Private members though, wouldn’t even think of testing directly against them and can’t think of many situations where I’d have wanted to.

  • Ian Cooper

    @ Colin

    Yes I was making a separate point which is to question why you want to hide information that your tests needs by making it private, just because no one other than the test needs it. If I hide it them I do not want you to depend upon it and reserve the right to change it. But if I expose to tests via InternalsVisibleTo, something now depends upon it and so will be impacted when I chose to change it.

    Tests drive needs. So if my tests needs to know about that property of the object or call that method, I would suggest that the test is telling you that it should be public.

    If you want to hide it from other consumers, because you think that they should not depend on it use separate interfaces to distinguish between the two roles that we have, client of production code and client of test code.

    I’m suggesting that the needs of test code are first order needs the same as production code.

  • http://colinjack.blogspot.com Colin Jack

    @Jeremy
    Sure but I think Ian was perhaps making a seperate point (or I read it differently).

    On the internal bit, in our case when you import (for example) our domain model we want you to see the key domain entities/services/value objects etc but not all the nitty gritty classes that we created to hold the details. If you make them public then people aren’t going to know which are key domain concepts are which are just classes we had to create to support that design. Design wise I wouldn’t see it as wrong if a developer chose not to use any DBC on an internal class that is used once, but I would always expect some effort on the public interface.

    To be honest its not an issue for us anyway, InternalsVisibleTo lets us get into testing the nitty gritty directly when we want to.

    Not sure what you mean by “the public facing classes are simply in the root namespace, so who cares?”, I’m probably being dim though.

    Anyway ta for replying, interesting discussion.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Colin,

    Marking methods and fields as private is a totally different issue than making classes internal or sealed. Encapsulation is good, but I’m just not that concerned about making classes internal. Maybe with something that’s really a library I suppose, but even then, the public facing classes are simply in the root namespace, so who cares?

  • http://colinjack.blogspot.com Colin Jack

    @ Ian
    Oh and I didn’t mean the first comment in the reply to be glib, I just re-read it and it came out badly. Gotta stop being so terse in my replies because it just makes them sound rude! :)

    All I meant is personally the access specifiers help as one part of providing encapsulation which I definitely value.

  • http://colinjack.blogspot.com/ Colin Jack

    “is the point of making something private – to hide an implementation detail we don’t want you to depend upon because we reserve the right to change it.”

    Pretty much, encapsulation.

    “Maybe we should ask the question whether a test forcing you to surface a field or property is an indicator that it is not an implementation detail but information about the state of the object or an operation that needs to be exposed for certain types of interrogators”

    We should, but often the exposing of the details would only be to make it easier to test.

    If you have an encapsulated class/member then I personally think making it public just to make it testable (without using InternalsVisibleTo) is overkill. Maybe in some cases it helps but in a lot of cases making something public is (to me) making it part of the contract with your clients and needs to be done carefully.

    “I think the problem here emerges from devaluing test code by comparison to production code. I’m not sure that is a valid distinction any more and could be easily deconstructed. I would suggest that the responsibility ‘be testable’ is valid concern for any class even if the role it is fulfilling is application and not domain specific.”

    Not sure, do you mean devaluing the tests?

    My view is to make a class “testable” I shouldn’t (and usually don’t) have to make any sacrifices in design. If I think a test related change is enhancing the design then great. However if it means exposing implementation details that in a good OO design would be hidden then I won’t do it (unless not exposing them makes the code completely untestable).

  • Ian Cooper

    @Colin

    I’m not sure people have not become knee jerk around access specifiers. What is the point of making something private – to hide an implementation detail we don’t want you to depend upon because we reserve the right to change it. Maybe we should ask the question whether a test forcing you to surface a field or property is an indicator that it is not an implementation detail but information about the state of the object or an operation that needs to be exposed for certain types of interrogators. I think the problem here emerges from devaluing test code by comparison to production code. I’m not sure that is a valid distinction any more and could be easily deconstructed. I would suggest that the responsibility ‘be testable’ is valid concern for any class even if the role it is fulfilling is application and not domain specific.

  • http://colinjack.blogspot.com/ Colin Jack

    Ta for the reply.

    “By and large though, testability largely follows the direction of better cohesion and coupling qualities anyway.”

    I agree but I’ve also seen some designs that I wouldn’t go for created in the name of testability, such as making everything we need to test public. Mind you we (mis)use InternalsVisibleTo for that instead so its 6 of one…

    “Forget about interactions within your domain model”

    Yeah, up till now we have.

    Having said that BDD would be driving you more towards actually treating these interactions as roles (if my understanding is correct) and creating interaction tests for the high level interactions.

    “In these cases, you may not want other classes or layers to be intimately knowledgeable about the raw getters and setters in the Domain Model”

    We’re definitely not treating the domain as a bunch of getters/setters and as much domain behavior as possible is in the domain proper.

    Despite this of course you need the getters/setters for CRUD/maintenance scenarios (unless you have two models, but we don’t).

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Troy,

    I’ll get flamed for this, but I just mark anything I want or need exposed to unit testing as public and don’t worry about it. I just don’t see much value in being paranoid about marking things as internal. I’ve never felt any pain from having classes marked as public, and I’ve been burned by frameworks that try to lock down the code with scoping and sealed classes.

    @Colin,

    If making a change for testability improves the team’s productivity and throughput, I’ll make the change. By and large though, testability largely follows the direction of better cohesion and coupling qualities anyway.

    ISP with Domain Model classes. Forget about interactions within your domain model. You may practice ISP when a Domain Model class is exposed directly to a service layer class or an MVP Presenter to prevent tight coupling. In these cases, you may not want other classes or layers to be intimately knowledgeable about the raw getters and setters in the Domain Model. Instead, you can “force” more logic to stay within your domain model where it belongs by only exposing methods and operations from the Domain Model to the service layer. Think of it as a way to enforce Tell, Don’t Ask and improve encapsulation along the way.

  • http://colinjack.blogspot.com Colin Jack

    The Mock Object guys stuff is good, I came across it because Steve Freeman was good enough to answer some of my questions on the TDD forum and he provided links. I think I’m going to start a thread about this on the DDD forum to see if people really use interaction testing to extract meaningful roles for their domain entities though (as always I only think of the domain).

    I also agree with this:

    “Break dependencies in unit tests only with techniques that I would be willing to use in the production code.”

    But I would equally say we shouldn’t make changes to the design in the name of testing that we don’t believe improve the design in general. I’m also still not convinced that the benefits of testing very granular classes or introducing ISP within a domain model but I am beginning to look at the topic again.

  • http://tgould.blogspot.com Troy Gould

    What are your thoughts on internal methods and marking classes or AssemblyInfo.cs with InternalsVisibleTo in order to be able to test?