Having started my professional career as a Tester (SDET) at Microsoft, this topic resonates with me. In my experience testers need to be more aggressive and assertive with the code their developers have written. Obviously this implies you've already established a good relationship with your coworkers, but you shouldn't be afraid to tell developers that their untestable code needs to be given a second look. It's not pleasant telling someone "their baby looks ugly," but that is one of the responsibilities of white box testers.<p>Dependency Injection greatly improves the landscape. Don't instantiate concrete classes when you can have a DI framework construct those objects for you. This will allow you as the tester to supply the mocked objects rather than taking the wrapper approach. It is better if as a team you've introduced this design decision up front, but you can introduce it later for problematic classes that need extra attention. In Java, I love using Guice for this sort of thing, in .NET I've used Ninject in the past.<p>One thing that .NET has in its favor that Java doesn't is partial classes with an internal access modifier. You can then put your test code in these partial classes and grant them access to your assembly. This allows you to separate your private test code hooks from your shipping code, and it prevents someone from deriving from your class and using those test interfaces incorrectly.<p>This line is the problem: public WebClient client = new WebClient(); client shouldn't be public and it shouldn't be using a concrete class. Introduce an interface, use DI, and use internal partial classes as needed. If your developer won't do this, find a new developer. Anyone can write code, but writing good testable code with a clean separation of intents is something some developers never learn, usually because no one has told them, "You're doing it wrong."