testability

Somebody tasked with creating a "Core" set of libraries created a set of static classes providing all sorts of utilities from logging, auditing and common database access methods. I personally think this stinks because we now have a Core set of libraries that are hard to test because I can't mock / stub these classes or do any injection into their constructors. I suppose I can use TypeMock to stub these out but I'd rather do it for free. What do you think? Edit If you don't think they're hard to test could you give an example of how you would test them. These static classes instantiate other

I have been developing a command-line tool which calls System.exit() ( don't want to use exceptions instead of ) on certain inputs. I am familiar with Java: How to test methods that call System.exit()? and its the most elegant approach . Unfortunately, it is not enough pure, due to I had to add the dependencies to system-rules , junit-interface Is there any common pattern for dealing with System.exit in specs2 which is more pure than my current approach which don't use specs2 ? import org.junit.Rule; import org.junit.Test; import org.junit.contrib.java.lang.system.ExpectedSystemExit; public

While designing my objects I find composition to be a better choice from the perspective of testability. The reason being, I can mock parts of the composition structure if I need to, while running unit tests. This is not possible if I have an inheritance hierarchy. I would like to know if others have also found this to be a reason to prefer composition. Also what other testability pitfalls did you get into because inheritance was used? I believe that the more you start to develop using design patterns, you'll find more and more often where composition is going to be favored over inheritance. I

All, Wanted to get a few thoughts on this. Lately I am becoming more and more of a subscriber of "purist" DI/IOC principles when designing/developing. Part of this (a big part) involves making sure there is little coupling between my classes, and that their dependencies are resolved via the constructor (there are certainly other ways of managing this, but you get the idea). My basic premise is that extension methods violate the principles of DI/IOC. I created the following extension method that I use to ensure that the strings inserted into database tables are truncated to the right size: