Archive for February, 2012

Impressionable Programmers

I’d like to meet some programmers interested in Ruby/Rails (or experts in it for that matter) around the St Louis (St. Charles) area.  Leave me a comment if you’re interested in getting together for some geek talk at a local coffee bar or whatever.

A Weekend Off

Sometimes it’s a good idea to take a weekend off entirely.  I’m not doing anything super technical, or even a slight bit technical.  I’m giving my brain the weekend off!

Personally, I Do Care

Here’s to you coders. I’m not sure why I do it, but I take my code personally. I try to own everything I do. I feel that owning our product would be best if we all worked this way.

When I’m responsible for a flaw in a system, I take it personally. This being said, I try to fix it as fast as possible. When these issues are on public (open source) projects, I’ve found myself even more pressured and overwhelmed to get it fixed. So here’s to testing.

Over the past few years, I went from head down coder, to systems administrator, to code maintainer; and just about all the roles in between. When I started, I couldn’t write good test, I barely knew what testing was. Then Rails got me on the hook, and now I can’t write code without tests; it’s just not right.

Write your tests, when you find a piece of broken functionality, write a test first. If you can’t write a test first, figure out the problem, and then write the test. Once you have a test that fails, then make the change. Make sure all of your tests are passing.

What kind of tests? Unit tests, for testing methods and method expectations. Functional tests, to make sure it’ll work when the code releases. Integration tests to make sure your fix will work with all the other stuff out there.

Why test? Without tests, whatever the flavor, your code base will never mature. Coders come, and they go. Bugs come in, and they get fixed. If you decide to do this for a year (or three) without increasing test coverage, then there is no software maturity. And we need to mature our products or else they lose maintainability; and some times that means tens of millions of dollars straight down the drain.

What happens when you can’t test everything? I’m still learning this role. Especially in the open source world. There is just no way to account for the ways in which everyone uses the product which you are helping to support or enhance.

I recently went through this process, find an issue or enhancement. I have to reproduce the issue first, to get a good picture of where I’m going. Write some tests and make sure the issue still presents. Then implement your code, making sure to write unit tests to cover any new or old uncovered code you run across that is affected by your additions. And once you’re done, it’s just going to work!

Not always. My recent issue was tested against a certain database (sqlite), and I know none of the product’s customers use this data-source in production (okay, well some of then certainly do!).  My lesson learned here… If at all possible, even if it’s just locally, create some configurations to run your tests against all the different configurations your users might be expected to use the code. I’m going to aim for 90% coverage (as I can’t account for 100% of the ways people will use my code)!

What tests do I use?

  1. rspec (spec/integration/requests/mocks)
  2. cucumber (functional/integration/requests)
  3. factory girl (model factories)
  4. capybara (requests)
  5. shoulda (must have for ANY project)

I have used others as well. And I rarely use all the above in a single project.  I think you’ll find rspec and factory girl in every project. I choose between rspec requests or cucumber depending on several features.

When I started, I wasn’t comfortable writing test, but I don’t think anyone is.  I only heard myths of testing when I was in college, and even less in Enterprise.  As I have evolved over time, I don’t feel comfortable writing code! (You heard me right, but let me quantify the statement).  I don’t feel comfortable jumping right into complex scenarios and projects and just banging away at code.  The code bases that I feel best about jumping into, are the ones that have a reasonable test suite (don’t worry if it’s not perfect, we’ll get there).

Testing won’t solve all the issues you will see.  But as you continue to increase coverage and add tests, you will see an amazing transformation.  You will see your code base become more stable; you’ll see your customers become much happier; you’ll see your precision and productivity sky-rocket (it’s almost exponential).

© 2012 - Jeff Ancel
Wordpress Themes
Scroll to Top