Posted: March 24th, 2011 | Filed under: .NET, Libraries, Unit Tests
Author: Tom
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 »
Tags: .net, c#, development, FakeItEasy, quaility, unit tests
Posted: March 22nd, 2011 | Filed under: Culture, Software Development
Author: Tom
No Comments →
Let me start with admitting that I just pushed out a shamefully buggy set of performance enhancements. I had done a lot of testing, but I hadn’t considered the enormous number of places my changes impacted and we spent the next two weeks picking off another 5-10 bugs that I had missed. All of the bugs would have been easily caught by even relatively comprehensive unit tests.
I hate to admit that my team’s does not have the habit of writing unit tests, or generally testing well at all. I am the one that should be setting the tone for these things and I have dropped the ball. We started off on the right foot (sort of) a couple of years ago with a moderate set of unit tests but as things continued those tests weren’t maintained and to be honest the speed in which we were having to refactor and transform the app overall in the first year made it incredibly difficult. In fact, those tests got so far out of date within a couple of months that we just dropped them out of the primary solution so none of us had to deal with them.
Our code base, team and the scope of the business solutions we’re providing is well beyond the point where unit tests became a necessity. But, it’s really tough to backfill an application the size of ours with tests. The app isn’t huge, around 100-150k logical lines of code, but it’s way too big to have the lackadaisical approach to testing and quality that we have. We don’t have any dedicated QA resources at the moment so we have a peer review process that breaks down a lot. So with a lack of unit tests, a lack of a well defined QA process, and a constant rush on whatever is next, we simply don’t have a Culture of Quality.
As I’ve said, I believe this largely is my own fault. I haven’t pushed back enough on some business demands to make it clear we need more time for testing. I’ve jumped into refactoring & enhancements without full recognizing the implications of those changes and I haven’t pushed my team enough to see the value of tests, not to mention simply making a rule of requiring tests for new development.
Read the rest of this entry »
Tags: bugs, code quality, development, team culture, testing
Posted: March 17th, 2011 | Filed under: .NET, Programming
Author: Tom
No Comments →
There is a group of developers out there who seem to think that tools like ReSharper or CodeRush or a similar tool are a border-line requirement for their jobs. And while I considered linking out to their many, many blogs describing how important it is, I chose against it. Mainly because I don’t want it to seem like I have a problem with them using these types of tools. I just can’t make sense of it.
I installed ReSharper a few months back and I loved it… for 3 days. I was cleaning up code and refactoring all the time but by my fourth day I was back onto a big project and didn’t have time for code cleanup and refactoring. As soon as I switched gears back into development, I started to find resharper irritating. It slowed down my environment. There was always some window it popped up on my screen getting in the way. The Resharper intellisense was consistently placed poorly so it was blocking code I needed to see. It was just in the way; always and forever in the way. I couldn’t take it. I think it was day 5 that I got an email from the Resharper folks asking me to fill out a survey on their product. So I did. Happily.
I blasted it up one side and down the other and then uninstalled it. But then I thought, I liked it for a while, maybe the problem was just that I didn’t like the feel of ReSharper… maybe a different tool with a different interface wouldn’t bother me so much. So I decided to try out CodeRush. I was already sick of things being in the way and my Visual Studio being slowed down. It lasted all of about 3 hours. Sure it did more or less all of the same things as ReSharper, but it was still in my way.
I’m a minimalist all around. I like things simple. In fact, my choice editor is UltraEdit. I find intellisense only mildly useful. The code clean up, sure that’s nice, but only because some people earlier on my project didn’t have the discipline to keep things clean to begin with. The refactoring, honestly wasn’t that much easier than what’s built into VS2010 out of the box so it’s not offering much there, not to mention that I barely use what’s there anyway. Visual Studio has made great progress in 2010 in being lighter, not heavier (hats off to the VS2010 team for that). I don’t want anything that’s a step back in that regard.
At least in the .NET world it seems that guys like me are a minority, I want code, pure and simple. These types of tools don’t keep me as in touch with my code, or with the discipline of writing good code and keeping it clean. My guess is, people who like ReSharper probably love FireFox and have a million plugins. Me? I use Chrome and I have one plugin and that one plugin I use about once a month, if that. I want fast, light and out of the way (if only the UI on Opera were cleaner I’d probably use that…).
The point is, you don’t have to use some crazy collection of Visual Studio plug-ins to be a good coder. More specifically those plug-ins don’t make you a good coder; though they may make it easier for you to be the good coder you already are. Equally, if you’re a bad coder, a tool like this won’t hide it. At best it will probably just make it easier for the rest of your team to tolerate your work. This really applies to anything, I’m a terrible carpenter for instance. Tools won’t hide that. In fact, more elaborate tools just make it easier for me to build something big enough to cause real problems when the truth of my skill is realized.
Tags: c#, coderush, resharper, tools, visual studio
