This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: The Space for Names in TDD
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
This just sort of popped up onto my radar after reading Roy's post on creating group projects under a single solution. Roy states the advantages of this from a TDD perspective as follows: "For example, usually I'll have a pair of projects for each Application tier, one for unit tests and another for the tier implementation (“Dal“,“Dal.Tests“). Using such a folder scheme as mentioned above I'd have a folder under my solution called “Dal” under which these two projects will reside."
While I agree that the group project idea is great, the one thing that bothers me is the example. More specifically, the namespaces there. Anyone see it ? It's right there, "Dal", and "Dal.Tests". No takers ?
The problem with this arrangement is that all classes in Dal.Tests will be a part of the namespace Dal as well. What this means is that any internal classes to Dal, which you obviously didn't want anyone to know about outside the Dal project, are suddenly accessible in Dal.Tests !
Now, if you are the only developer working on both Dal and Dal.Tests, you'd probably remember not to make any use of InternalDalClass or any other internal classes. But, in many cases you're not the only developer. And in almost all cases, you're not going to be the only one maintaining the code over time. So, some other developer when writing a test class in Dal.Tests would see just another class he could use to test the functionality of Dal.
This is OK if you intend on doing white box testing. However, I think that it is generally agreed that black box testing be done outside the project (Dal) while white box testing be done within. ( If it's not generally agreed, well, sorry, but I've seen it done a lot, and the logic behind it makes more sense than all the alternative approaches I've seen. )
So, for black box testing, instead of "Dal.Tests", just call it "DalTests" and voila, a separate namespace where the internal classes of Dal are not accessible.
Previous Topic
