PL/SQL has unit testing support and tooling, but my sense is that it’s far from the world of Java or Ruby. In most modern OO languages unit testing is just a part of the landscape. TDD is evolving to BDD with tools like RSpec and modern web frameworks come with unit testing support built in from Wicket to Rails.

It’s a little different in the Oracle world. Steve Feuerstein the evangelist for TDD and unit testing in PL/SQL mentions:

utPLSQL is used by many development shops, but not nearly enough to make it a standard in the PL/SQL environment.

The difference is JUnit is a defacto standard in the Java world. Steve developed utPLSQL to allow for automated unit testing in PL/SQL and has been pushing the idea ever since.

utPLSQL is a basic xUnit framework with assertions, setup and teardown. The interface is simple with no red/green bars just a ‘success’ message in ASCII art. There is a GUI front end runner called OUnit, but it hasn’t been updated in quite some time. The current leading edge unit testing tool is a commercial offering from TOAD called Quest Code Tester for Oracle.

Steve Feuerstein is the developer behind the tool. At first glance it looks like a nice option especially since we’re a TOAD shop. I’ll probably delegate it out to one of our developers to really look into it. The questions I still have are:

• Write a failing test. Write the code to make it pass. Refactor. How painful is manual refactoring in a procedural language?
• How do you hook up the test runs to a continuous integration server? And are you tied to the TOAD tool?
• How do you deal with all the actual dependencies on data in tables for tests.
• How do you avoid slow running tests?

Two weeks into the new app dev manager with a new organization. After moving through this transition a few times I can pass on the following advice:

• Start your one-on-ones or continue the existing ones.
• Spend a lot of time talking and walking around. Your brand new, and you need to get out and start getting a sense of the people and the organization.
• Gather your project and application portfolio. At this point the acronyms and lingo are still confusing, but you have to get a sense of where your projects are and whether any of them are struggling.
• Stay organized. You’re on a nasty learning curve for the first few months and the last thing you want to do is let your email, physical inbox, and voicemail start overflowing. (GTD works for me here.)
• Enjoy the surprises. Every organization has it’s own way of doing things and at least once a day for the first few weeks you’ll have some underlying assumptions shattered. In an earlier job in my career I remember picking my jaw off the floor about one week in. One of the developers on Project X Phase II explained Project X Phase I had never been deployed to production. Some unrelated projects had been rebranded as Project X Phase I so the team could declare victory on delivering phase I.
• Don’t make big changes those first few weeks. You don’t have the data yet.

This week I started fresh with a new company and a new title. After four years as a Software Development Manager and a short stint as an Enterprise Architecture Manager I’ve now returned to managing a group of internal IT developers. The current title is Application Development Manager.

The new organization is full of opportunities and challenges. Some of these include:

• Inheriting a senior development team.
• An organization which is still early in the process of formulating practices and process.
• High level support for process improvement a mix of CMMI, ITIL, PMI, and a bit of RUP at present.
• Systems with real high availability requirements.
• A JBoss shop.
• A QA team pushing hard to push for quality throughout the project and not just at the end. Plus they’re doing automation and load/performance tuning.
• Developers self-organizing a weekly gathering to discuss software topics.

I wake up about 5 am these days to go for a walk every morning. These days it’s a lot easier to bounce up and not just hit the snooze button. If I can get Perforce setup with a Hudson plugin I might just set up a continuous build box tomorrow.

A sense of fun can help new practice adoptions. After reading a post by Clint Shank on coming up with a continuous integration game Erik Ramfelt went ahead and created a Hudson plugin.

Currently the points you get are:

• -10 points for breaking a build
• 0 points for breaking a build that already was broken
• +1 points for doing a build with no failures (unstable builds gives no points)
• -1 points for each new test failures
• +1 points for each new test that passes

Looks like a good starting point. I really like the idea of getting points for implementing new tests.

As a manager of developers I have a goal of trying to provide at least one week of training per year at a bare minimum. For senior developers or even journeyman developers in transition the best available option is often a conference. The benefits far outweigh the costs:

• Exposure to software development outside of your small corporate IT shop. I know people read blogs and books about software, but talking to real people can bring the message home. I had been evangelizing things like TDD and continuous integration among my developers, but when I sent four of them off to a conference they all came back saying, “Wow, this TDD stuff, design patterns, and agile really are big deals. I had no idea.”
• Proving your company really is about the people in it by investing in them. There’s lots of talk at most companies about how much they value their employees, but when it comes down to it training requests are denied on a regular basis. And since so many companies pay lip service to training actually providing it can be a major recruiting advantage.
• One conference can pay dividends throughout the year. Your developers come back with lots of new ideas and continue to research and bring these ideas into their day to day development. Your code base will actually get better and your developers will be more productive. And that extra kick in their step around the office is the sign of a re-energized employee. Energized employees are a great asset.

Unfortunately this is the most common experience:

Nearly a year ago, I posted a question on Spring Forum entitled, “am I working for the wrong companies or is it just not that common to attend conferences?”. I’ve worked as a developer for over six years and as yet I’ve never had the opportunity to attend a single conference. I thought I might be alone in this, but I’ve spoken to a large number of developers who are in exactly the same position, some of whom have worked in the industry far longer than I have.