Instantiating an object in Java without calling a constructor

The Scenario

This isn't a cliche...

I was working on a Java project that talks to a web service with a custom "Client" class that was written internally.  In my project, the client is pulled in from a hosted maven repo as a dependency, so I didn't have access to the source (at least not from this project).  I'm trying to be better about writing characterization tests for existing code before I go in and change anything (if nothing else it's a good way to feel out the code). But I had a problem...

The Client has a single constructor, which takes an endpoint, a username, and a password. Calling this constructor tries to connect to the endpoint (and crashes if it fails).  Because this was the only defined constructor, subclassing wasn't going to help me.  It doesn't implement an interface, so that avenue was also closed down.

So there was no obvious way for me to create a test double to pass in to the code I was actually interested in testing.  How in the hell was I going to get around this???

Making assertions with jUnit against log4j console output

I will open by saying that making assertions against your log output is probably a bad idea.  Probably violates every rule of good testing.  That said, I found myself writing characterization tests against some legacy code and I wanted to make sure I didn't break the logging.  So I decided to write some flakey, brittle unit tests.  It was several hours of pain, and I figured it would be a good idea to document my pain so you can avoid some of it (hopefully by not following in my footsteps at all... sigh)

Pitfalls of trying to mix Entity Framework providers for SQLite and SQL Server

As part of my annual evaluation, I was given the task of figuring out how we might use an in memory database (such as SQLite) to run integration tests against instead of using the full test database (SQL Server).  I was initially optimistic, but after some experimentation I have decided that this approach is fundamentally flawed.  While I think you could theoretically pull it off, you would never recoup the amount of work involved.  Ultimately, I think for integration tests you are better off just pointing EF at a test database of the same type.

ASP.NET MVC Unit Testing Part 4: The Tests and What Was Learned

So, now that the project is refactored with interfaces, I have fake data, and a fake environment, it's time to run some unit tests! Whoohoo!  I'll go over some of the basic tests and also cover what I learned over all throughout the unit testing process.

ASP.NET MVC Unit Testing Part 3: Faking the Environment (HttpContext)

So I have my fake data, but I also need to address additional dependencies that are not as obvious.  These dependencies arise from the use of User and Request, which are properties of the HttpContext.  Because you apparently can't assign HttpContext directily, you have to create a fake ControllerContext.

ASP.NET MVC Unit Testing Part 2: Faking the Database

Now that the production code is all set up, it's time to create the fakes that I'll inject for my unit tests.  Rather than connecting to the production database, I want my unit tests to use an in memory dataset so they will run lightning fast.  There are limitations to using in memory data (in effect substituting LINQ to Object for LINQ to Entities) which I will address in another post.

ASP.NET MVC Unit Testing Part 1: Set up

So, a little background here first.  I'm pretty new to .NET programming, having only started my first developer job just this past March.  My one and only performance management goal was to implement some unit testing.  Simple right? Well my first feeble attempts involved trying to add unit tests to a traditional ASP.NET program... come to find out unit testing code behind files is a fools errand.  Did manage to test come CRUD on a service class, but all in all it wasn't that useful.  I was also attached to a new development project called Education Assistance (EA around the water cooler) that was using MVC.  I'd read that MVC was much easier to unit test so I figured that would be a possibility at some point.  Of course, first I had to learn a little about MVC.  I worked through a few tutorials, a couple of which actually covered unit testing.  So now I knew just enough to get myself in trouble.