No Comments →
So I spoke a little about how I’ve become committed to changing the culture on my team. And I’m starting that with an effort in backfilling our app with unit tests. It’s a tremendously large task and to be honest I’m finding it really exhausting, annoying and I’m having a hard time seeing the benefits.
Then I realized that I’m just thinking about unit tests wrong, being too detailed and too broad in each test. This makes them both annoying and complicated to write as well as not really accomplishing their true goal. One of the challenges that I’m having is basically that there’s a big chunk of our application that’s nothing but forms over data. And that gives you, well, not much to test.
We have a three layered design for UI, Business Logic and Data Access. Common stuff. We user Service Location and inversion of control so each service class has a lot of details that goes with it. It’s a pretty small number of places that have detailed business logic. Most of our service layer methods (where I’m focusing my unit tests at the moment) are either pulling data together to display, or updating the data store.
I started off all of my unit tests with complicated checks and ordered assertions to make sure that things are happening in the correct order and beyond that… basically that the right calls are going to the data layer and the right data is being returned. Now I guess I’m coming to the conclusion that I was way over shooting what these need to do and making the tests way too complicated. Seriously, some of these tests were around 40-50 lines long. Preparing all of the data that was going to be passed around. Setting up all of the mocks and all of the expected calls etc. It’s tedious.
Read the rest of this entry »