Thanks for the reply, Jay. I think I’m becoming convinced of your position. When I can next justify a decently-sized hobby project, I’ll try to do it in a dynamic language with lots of tests. I’ll probably do it in python.

I suppose the key will be to make sure there’s 100% code coverage and enough permutations to be confident of the code. How do you make sure your tests are getting enough coverage?

Thanks for taking the time to reply!

You setup a bit of a perfect storm by saying that the tests use a different logger.

I was trying to get in the idea of mocks. Some objects rely on I/O; say, a logger, a database connection, or a file. When unit-testing something that calls it, you want to swap out the logger/connection/file for a mock object. Otherwise you’ll hammer your event log, database, or file system when you run your tests.

So let’s say I’m now running a function which calls the logger; say MyDocumentedProcedure(). During testing, I always set the global Logger to a new MockLogger. Well, MyDocumentedProcedure() may work absolutely fine because MockLogger is set up correctly. However, if ProductionLogger hasn’t been updated, it’ll fail there. Of course, ProductionLogger should have it’s own set of tests, but there’s no guarantee that ProductionLogger’s tests aren’t just out-of-step with the new log(msg, sev) function.

I think it’s a matter of how you want to program — I’d like these sorts of errors found for me by the computer. It’s feels natural, and I’m fluent with it. That makes me productive with this kind of system.

@steve

You could use a default parameter for severity

The problem with this approach is that my requirements have changed. I’ve gone from the requirement ‘All messages are logged in the same way’ to, say, ‘messages have a severity of Alpha, Beta, or Release, and are logged differently based on the releaseType variable’. Much of this requirement is enforced throughout the code when I change the method signature to

log(string message, LogSeverity severity)

def log(message, severity=”low”):

or do a search in files for log(

Second, the tests should catch the errors. You setup a bit of a perfect storm by saying that the tests use a different logger. This may get through the tests, but our staging server would catch it before it ever hit live since it emails me every time there is an error and a bad logger would error almost immediately.

In the past few years I can recall 2 or 3 times that there has been a bug from dynamic code, none of it ever hit the live server, and it took maybe 1 day total time to hunt them down. Most of that time was one particular bug. How much time did we gain in productivity using ruby compared to what we lost with these bugs and the slower but infrequent refactorings? No one knows for sure, but my money is that it’s been a net plus for me.

have you read “Working effectively with legacy code” by “Michael C Feathers”?

No, I’ve never seen it. I might have to search it out next time I’m in borders.

I’ve seen something similar to the actionscript behaviour in Ruby — when you call a non-existing method, it actually calls another method called missing_method, which throws an exception. However, it can be overridden, which means you can specify a kind if ‘oops, sorry’ behaviour to get things back on track. Either brilliance or pure evil. Or both.

Actionscript will helpfully call the new log function with a null parameter where you’ve missed one out, but if you accidently type a function and called lgo(msg) instead it will just ignore the call and not raise an error message or anything! That’s what you get for using a language that you can dynamically add functions to objects on the fly.

In a similar vein - I like strongly typed languages.

In other news - have you read “Working effectively with legacy code” by “Michael C Feathers”? It’s all about moving towards good testing practice in existing code (rather than all the books about good testing practice that start by assuming you’re writing a brand new project and don’t have any dirty code to start with); and a relatively entertaining read for a dry subject.