Castle Windsor, unit testing and class visibility - am I doing it all wrong?

[Andy]

I'm developing a WPF desktop app, which is fairly "self-contained" - there is no public API or anything like that. I'm using Castle Windsor for my DI needs. While I understand the need for interfaces where there a possibility of change, I still often end up creating an interface for each class, even though there will only ever be one concrete implementation. I do this just to make it easier to unit test a class, allowing me to mock the interfaces injected into its ctr. If I didn't create these interfaces, the only way to mock such dependencies seems to require the addition of a public, parameterless constructor to those classes, and make their members "public virtual". Neither approach feels quite right - adding artifacts in my code just to support unit testing. How do others tackle this?

I also struggle a bit with class visibility. I find that most of my classes are internal, but with public constructors (to satisfy Castle Windsor), and public members (to satisfy unit testing, as above). Again, it doesn't feel right having this odd mix of visibility in a class - or am I worrying unnecessarily? Similarly, let's say I have some public classes (e.g. helpers) in a shared/reusable library, and these have dependencies of their own that I don't want exposing publicly. I can't make these dependencies internal (you can't inject an internal class into a public ctr), so these classes end up being public too. Is this a problem, or does visibility only become important when developing some kind of customer API?

Thanks in advance

Andy

[Adam Connelly]

Hi Andy,

I personally don't think it's a big deal. I also create interfaces for my classes just so that I can unit test the different parts of code independently. At the end of the day, if you don't create an interface then you're not really unit testing, because you're depending on actual instances of the dependencies. So I'd stick with what you're doing.

About visibility - I honestly don't think it matters if you're not creating a public API. And even then, the only reason I'd care about visibility would be to make the API easier to understand for consumers. I personally hate using internal visibility. In my experience, all it ever does is causes me grief. Especially when third party libraries end up making objects that I need to create for the sake of unit testing with internal visibility. My vote is to avoid internal and sealed like the plague.

Basically, I wouldn't worry about it.

Cheers,

Adam

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/d/optout.

--

Adam Connelly

Software Developer

    

View our Short Video presentation

Sales.......+44 (0)207 871 7491

Support....+44 (0)207 871 7490

DDI..........+44 (0)141 404 1441

Restaurantdiary.com Ltd. Registered in Scotland | Company No. SC258100 | Registered Office: 75 Bothwell Street, G2 6TS

VAT Registration Number: GB829960776

PCI Compliance