Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

With the some most common languages (Java, C#, Java, etc) it sometimes seems that you are working at odds with the language when you want to fully TDD your code.

For example, in Java and C# you will want to mock any dependencies of your classes and most mocking frameworks will recommend that you mock interfaces not classes. This often means that you have many interfaces with a single implementation (this effect is even more noticeable because TDD will force you to write a larger number of smaller classes). Solutions that let you mock concrete classes properly do things like alter the compiler or override class loaders etc, which is pretty nasty.

So what would a language look like if it was designed from scratch to be great to TDD with? Possibly some way language level way of describing dependencies (rather than passing interfaces to a constructor) and being able to separate the interface of a class without doing so explicitly?

share|improve this question
    
How about a language that does not need TDD ? blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey.html –  Job Aug 25 '12 at 15:25
1  
No language needs TDD. TDD is a useful practice, and one of Hickey's points is that just because you test does not mean that you may stop thinking. –  Frank Shearar Aug 25 '12 at 16:27
    
Test Driven Development is about getting your internal and external API's right, and do so up front. Hence in Java it is all about the interfaces - actual classes are byproducts. –  user1249 Aug 25 '12 at 16:43

4 Answers 4

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.

share|improve this answer
1  
I agree that interfaces are great and a key design element. However, in my code I find that 90% of classes have an interface and that there are only ever two implementations of that interface, the class and mocks of that class. Though this is technically exactly the point of interfaces, I can't help feeling that it's inelegant. –  Geoff Aug 25 '12 at 15:55
    
I am not very familiar with mocking in Java and C#, but as far as I know, a mocked object mimics the real object. I frequently do dependency injection by using a parameter of the object's type and sending a mock to the method/class instead. Something like function someName(AnotherClass $object = null) { $this->anotherObject = $object ? : new AnotherClass; } This is a frequently used trick to inject dependency without deriving from an interface. –  Patkos Csaba Aug 25 '12 at 16:01
1  
This is definitely where dynamic languages have the advantage over Java / C# type languages with respect to my question. A typical mock of a concrete class will actually create a subclass of the class, which means the concrete class constructor will be called, which is something you definitely want to avoid (there are exceptions, but they have their own problems). A dynamic mock just leverages duck typing so there's no relationship between the concrete class and a mock of it. I used to code in Python a lot, but that was before my TDD days, perhaps it's time to take another look! –  Geoff Aug 25 '12 at 16:06

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.

share|improve this answer
    
Agreed, it's a very difficult question to phrase well. I think that what I mean is that current testing tools for languages like Java / C# feel like the language is getting in the way a little and that some extra / alternative language feature would make the whole experience more elegant (i.e. not having interfaces for 90% of my classes, only the ones where it makes sense from a higher-level design point of view). –  Geoff Aug 25 '12 at 16:16

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

Zero Button Testing

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.

share|improve this answer
2  
Haha, that's amazing! I actually quite like the idea of putting tests together with the code. It's quite tedious (although there are very good reasons) in .NET having separate assemblies with parallel namespaces for unit tests. It also makes refactoring easier because moving code, automatically moves the tests :P –  Geoff Aug 25 '12 at 16:21

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.

share|improve this answer
    
Great answer! You guys are starting to talk me back round to dynamic languages :) I think duck typing is the key here, the trick with .new would also be possibly in a statically typed language (though it would be much less elegant). –  Geoff Aug 25 '12 at 16:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.