Deleting Unit Tests

I regularly delete some of my unit tests, sometimes within minutes of writing them. Even as a TDD fanatic I’ve come to realize tests are just a means to an end. If I decide to write a constructor test when first designing a bit of code and delete it a few minutes later, nothing’s wrong. These sorts of initial tests can become redundant quickly since to you have to construct the object for all the later tests.

As you adjust to TDD there’s a tendency to see the tests as important code. Deleting them is the last thing you’d think of doing. It turns out just like with production code less tests are better easier to maintain and easier to refactor. And as an added benefit your test suite runs faster. Tests are path to good code and you get an added benefit of a regression suite. And besides everyone’s favorite checkins are ones where you remove more lines of code then you add.

Phone Screening Junior Candidates

Phone screening junior candidates is hard. With 20+ years of experience I find it hard to evaluate someone who’s new to the field or worked less than 6 months. What I’m looking for is potential, but I can’t fall back on traditional measures where I ask for evidence of a skill. Sure they might have a beginning grasp of some language or the ability to put together a bare bones web site or iPhone app, but I really can’t drill them on OO, Domain Driven Design, or functional programming.

My approach has been to touch on some real basics to determine they’ve at least been exposed to subjects they claim on a recipe. Then I dig for stories of how they picked things up, what they learned from mistakes

Step one, is read the resume. They tend to actually be one page! Note anything I should ask them about such as basic language syntax or their explanation of TDD. Second, is take a look at any open source code you can find, often github. Ignore that it’s sloppy or untested and just take a good look at it. Then if you have time you can do some Googling and see what kind of data you can find about their participation in the community or even just questions on forums or Stack Overflow.

Next comes the actual phone screen itself. I have a stable of questions I use, a few I always use and many that I sample based on the interviewee’s experience:

  • What have you done in 2 minutes or less? (I’ll let this go over 2 minutes if I’m getting good information, but sometimes you just have to tell people you need to move onto the next question.)
  • I usually warm up with a question about the disadvantages of inheritance. This often throws junior candidates, but you can get a pretty good sense of how much OO they really understand this early in a career.
  • As I’m a die-hard TDD/BDD type I always ask them to describe how they’d write a test in their current unit test framework. A surprising number of resumes that claim to practice TDD can’t explain the syntax behind writing a rspec or Junit test.
  • I’ll often ask a question about a situation where they didn’t have enough information to complete an assignment and how they handled that. Sometimes this sort of behavioral question throws junior developers and I have to reiterate that I’m not looking for a theoretical answer.
  • Then I’ll jump around from behavioral questions to technical questions. I might ask about what an index is or what they find most challenging about their current project.
  • Almost always I include a question on how they come up to speed on new technologies. I’m looking here for anything they learned that wasn’t just presented to them in a class or at their job.
  • Finally I wrap up with a few standard questions:

  • Why do you want to work for us?
  • Is there anything else I should ask you?
  • What questions do you have for me?

Every few months I come through the questions and usually add a few and remove the ones I never ask. I still wish I had a better process, but the most common theme to come out of junior phone screens is that they’re enthusiastic and they know at least what they claim on the resume.

RSpec stub_chain for legacy code

I got asked the other day about whether it was OK to use stub_chain when testing what turned out to be a legacy fat_model class of over 500 lines. There wasn’t much to think about as I replied it was OK if there wasn’t a lot of time in the story for refactoring since the code was already legacy, but it wasn’t my favorite tool. Even the documentation notes:

we recommend treating usage of stub_chain as a code smell

It’s a part I appreciate about Spec. It’s an opinionated BDD framework, but it allows you do use it in a way that works for you. I don’t love stub_chain or even less as_null_object, but when diving deep into badly covered code they can be a nice way to open up a seam in the code and allow you to start a big refactoring.

Dotcom Junior Devs 2.0

In case you don’t remember the crazy gold rush days of the first dotcom boom, let’s just say that this was a defining image of the times:

At the time you could land a well paying job at pretty much any dotcom with no more than some basic HTML skills and a willingness to learn. A wave of people swept in and made up a large part of the dotcom workforce. Having a background actually programming was really nice to have, but became almost an afterthought as VCs helped push the rush to bring in warm bodies. If you were in another field at the time and wanted to try out life as a developer, project manager, tester, system admin it was a great time to jump in. There was low risk and plenty of reward.

I worked for a director who had been a bartender until 1999. On a project in 2000 one team had a former translator, an office administrator, and a lawyer. All of them had bootstrapped up on books and built a few static HTML sites before they found their first jobs as developers.

I noticed early on that the talent pool had completely dried up when I opened up an office for a dotcom in 2000 in Las Vegas. Our main office was in SF and I was amazed at the number of hires they’d made that really didn’t have any coding skills. Vegas at the time had a pool of solid developers, but we’re not Silicon Valley and the hometown university is UNLV. Still on average we were able to get better developers typically with real experience. I remember my first time visiting SF in 2000 and noting that 90% of all the billboards in the city were advertising doctors, many focused on recruiting. I’d never seen anything like it.

The bar was almost absurdly low for developer in the dotcom boom. This time the bar has moved up a bit. Now the default entry into the field is a Code Academy or Dev Bootcamp experience. Having survived the dotcom boom and bust I think it’s a good thing that the really junior dev coming from non-science or engineering backgrounds actually has done some real coding before starting their first job.

We’ve dipped our toes into these waters in the past year hiring two junior devs who had gone through dev bootcamps. We’ve been pleasantly surprised by several things that we didn’t get from junior developers in the dotcom days:

  • They have pair programming experience
  • They actually write unit tests without prodding or coaxing
  • They understand that they’re on a steep learning curve and embrace it
  • They don’t have a lot of bad ingrained habits
  • They understand the basics of putting together a web site
  • They are used to source control, commit early and often, and open source

So the new Dotcom 2.0 junior developers have a leg up from the early 2000s. I think more of them will stay in the field. They put some real time and effort into switching or starting a new career an possibly a decent sum of money and they’re more likely to stick it out. And their baseline is a lot better. They’re all feeling really underprepared even in their first paying dev jobs, but they are far better off then the wave that came in the late 90s.

RSpec and the Death of Should

I love writing expectations like the following:

account.balance.should be_zero

It was one of the reasons I first fell in love with RSpec and had a reason to move from dabbling in Ruby to diving in. This was hard and clear evidence that Ruby crushed testing syntax of Java in a way it could never compete with. Just a beautiful DSL with a single little word ‘should’.

Expect has come along to replace and it accomplishes the same thing with a bit more syntax and parens:

expect(account.balance).to be_zero

It reads well, but I still like ‘should’ better and I’m not as upset as some about object purity and polluting objects with an extra method. Our development team concluded as much for the last few years. We’d put a quick vote up every 6 months or so to keep should() or bite the bullet and move onto expect. Should always won, but over time the objections became more mild and newer team members had gotten adjusted to expect elsewhere. When the vote came up again a few weeks back, we finally voted to default to the new expect syntax.

My vote had changed from preferring should to being neutral on it. Over time most of that came from working on newer Ruby open source projects and following the new expect syntax when adding tests in a pull request. Idioms and styles evolve and I’d seen enough adoption to justify retiring my old friend should(). The small benefit has been with Jasmine with its very similar expects now doesn’t lead to accidentally writing a should() in a Jasmine spec. I still miss should(), but having everyone use the same assertion approach is better for the group.