Many years ago I threw together a prototype that addressed a similar question; here’s a screenshot:

The idea was that the assertions are inline with the code itself, and all tests run basically at each keystroke. So as soon as you make the test pass, you see the method turn green.

It would be dynamically rather than statically typed. Duck typing would then do the same job that interfaces do in statically typed languages. Also, its classes would be modifiable at runtime so that a test framework could easily stub or mock methods on existing classes. Ruby is one such language; rspec is its premier test framework for TDD.

How dynamic typing aids testing

With dynamic typing, you can create mock objects by simply creating a class that has the same interface (method signatures) the collaborator object you need to mock. For example, suppose you had some class that sent messages:

class MessageSender
  def send
    # Do something with a side effect
  end
end

Let’s say that we have a MessageSenderUser that uses an instance of MessageSender:

class MessageSenderUser

  def initialize(message_sender)
    @message_sender = message_sender
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end

Note the use here of dependency injection, a staple of unit testing. We’ll come back to that.

You wish to test that MessageSenderUser#do_stuff calls send twice. Just as you would in a statically typed language, you can create a mock MessageSender that counts how many times send was called. But unlike a statically typed language, you need no interface class. You just go ahead and create it:

class MockMessageSender

  attr_accessor :send_count

  def initialize
    @send_count = 0
  end

  def send
    @send_count += 1
  end

end

And use it in your test:

mock_sender = MockMessageSender.new
MessageSenderUser.new(mock_sender).do_stuff
assert_equal(mock_sender.send_count, 2)

By itself, the “duck typing” of a dynamically typed language doesn’t add that much to testing compared to a statically typed language. But what if classes aren’t closed, but can be modified at runtime? That’s a game changer. Let’s see how.

What if you didn’t have to use dependency injection to make a class testable?

Suppose that MessageSenderUser will only ever use MessageSender to send messages, and you have no need to allow the substitution of MessageSender with some other class. Within a single program this is often the case. Let’s rewrite MessageSenderUser so that it simply creates and uses a MessageSender, with no dependency injection.

class MessageSenderUser

  def initialize
    @message_sender = MessageSender.new
  end

  def do_stuff
    ...
    @message_sender.send
    ...
    @message_sender.send
    ...
  end

end

MessageSenderUser is now a simpler to use: Nobody creating it needs to create a MessageSender for it to use. It doesn’t look like a big improvement in this simple example, but now imagine that MessageSenderUser is created in more than once place, or that it has three dependencies. Now the system has a whole lot of passing instances around just to make the unit tests happy, not because it necessarily improves the design at all.

Open classes let you test without dependency injection

A test framework in a language with dynamic typing and open classes can make TDD quite nice. Here’s a code snippet from an rspec test for MessageSenderUser:

mock_message_sender = mock MessageSender
MessageSender.should_receive(:new).and_return(mock_message_sender)
mock_message_sender.should_receive(:send).twice.with(no_arguments)
MessageSenderUser.new.do_stuff

That’s the whole test. If MessageSenderUser#do_stuff does not invoke MessageSender#send exactly twice, this test fails. The real MessageSender class is never invoked: We told the test that whenever someone tries to create a MessageSender, they should get our mock MessageSender instead. No dependency injection necessary.

It’s nice to do so much in such a simpler test. It’s ever nicer not to have to use dependency injection unless it actually makes sense for your design.

But what does this have to do with open classes? Note the call to MessageSender.should_receive. We didn’t define #should_receive when we wrote MessageSender, so who did? The answer is that the test framework, making some careful modifications of system classes, is able to make it appear as through #should_receive is defined on every object. If you think that modifying system classes like that requires some caution, you’re right. But it’s the perfect thing for what the test library is doing here, and open classes make it possible.

So what would a language look like if it was designed from scratch to
be great to TDD with?

‘works well with TDD’ surely isn’t sufficient to describe a language, so it could “look” like anything. Lisp, Prolog, C++, Ruby, Python… take your pick.

Furthermore, it’s not clear that supporting TDD is something that’s best handled by the language itself. Sure, you could create a language where every function or method has an associated test, and you could build in support for discovering and executing those tests. But unit testing frameworks already handle the discovery and execution part nicely, and it’s hard to see how to add the requirement of a test for every function cleanly. Do tests also need tests? Or are there two classes of functions — normal ones which need tests and test functions which don’t need them? That doesn’t seem very elegant.

Maybe it’s better to support TDD with tools and frameworks. Build it into the IDE. Create a development process which encourages it.

Also, if you’re designing a language, it’s good to think long-term. Remember that TDD is just one methodology, and not everyone’s preferred way of working. It may be difficult to imagine, but it’s possible that even better ways are coming. As a language designer, do you want people to have to abandon your language when that happens?

All you can really say to answer the question is that such a language would be conducive to testing. I know that doesn’t help much, but I think the problem is with the question.

Well, dynamically typed languages do not require explicit interfaces. See Ruby or PHP, etc.

On the other hand, statically typed languages like Java and C# or C++ enforces types and forces you to write those interfaces.

What I do not understand is what is your problem with them. Interfaces are a key element of design and they are a used all over the design patterns and in respecting the SOLID principles. I am, for example, frequently using interfaces in PHP because they make design explicit and they also enforce design. On the other hand in Ruby you have no way to enforce a type, it is a duck typed language. But still, you have to imagine the interface there and you have to abstract the design in you mind in order to correctly implement it.

So, though your question may sound interesting, it implies that you have problems with understanding or applying dependency injection techniques.

And to directly answer your question, Ruby and PHP have great mocking infrastructure both built in their unit testing frameworks and delivered separately (see Mockery for PHP). In some cases, these frameworks even allow you to do what you are suggesting, things like mocking static calls or object initializations without injecting a dependency explicitly.