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.

I've read a lot of things about TDD but I still have doubts. For example, I have these class diagrams:

enter image description here

It's a simple example, just to learn about TDD and mock objects.

Which test should I write first? Product, then Line and last, Order? If I do that, should I use Line and Product to test Order or should I use Mock Objects? When should I use Mock Objects? Should I use UML with XP and TDD?

I don't get these things yet.

Thank you and sorry about my english.

share|improve this question
add comment

4 Answers

Judging from the diagram, Product is a dumb data class, with no functionality to test. So I would start writing tests for (and implementing, TDD style) first Line and then Order, up the dependency ladder. It is usually sensible to have your lower level classes tested before starting work on higher level classes (i.e. which depend on the lower level). This makes catching bugs more efficient.

Whether you need to use mock objects depends on the actual dependencies of the tested class. If these are simple classes which you can easily instantiate and set up with any desired data/state required for your tests, you need no mocks. (This seems to be the case for your example design here.) However, if any of the dependencies is difficult to initialize / has extensive dependencies itself / has undesirable side effects / depends on an external resource such as a DB, then it makes sense to use a mock object instead.

share|improve this answer
    
As I said before, it was a simple scenario, just to learn about TDD and Mock objects... A great answer, thank you. And what about UML? Should I avoid it? –  user14239 Jan 24 '11 at 13:37
    
@thomas, no need to avoid UML, it does not conflict with TDD. UML is very good for visualizing / communicating design issues. This can be extremely useful at certain development stages. However, design evolves, and trying to keep a beautiful and detailed UML system diagram in sync with the code can quickly become a burden. So remember to throw it away when you don't need it anymore :-) –  Péter Török Jan 24 '11 at 13:42
1  
@thomas, btw the convention here is to upvote answers you find useful, by clicking on the up arrow next to the answer :-) –  Péter Török Jan 24 '11 at 13:49
add comment

Normally for testing you want to isolate the system/object under test, so you would mock anything that is outside of that. So using your class diagram, when testing an order object, use a mock for the line object. When testing Line, use a mock for Order and Product. When testing product, use mock for Line.

share|improve this answer
    
Since Product does not depend on Line, there is no need (nor way) to use a mock for Line there. Same for Line and Order. –  Péter Török Jan 24 '11 at 13:44
add comment

I don't see much need for mock objects here. As pointed out by others, you need those mostly if dependencies are difficult to set up.

For example we used them with Ruby on Rails projects when we tested controllers and needed a user login that would have required a call to another controller and storing part of it's information in a cookie. In this case it's helpful to mock a logged in user that returns true, when asked about a certain access privilege.

share|improve this answer
add comment

"TDD is primarily a design technique with a side effect of ensuring that your source code is thoroughly unit tested" -- Scott W. Ambler

The idea is to find the design by writing unit tests. In your case, it seems you already have the design in place, which kinda defeats the purpose of TDD (assuming your design is final).

Regarding mocking. If you want to mock, I suggest you mock Product when writing tests for Line and mock Line when testing Order. But it may be overkill here. I personally try to limit mocking as much as possible, and use it to decouple dependencies on external classes (such as database instances).

share|improve this answer
2  
I just have a simple class diagram... –  user14239 Jan 24 '11 at 14:05
    
-1 So thinking about the design (including scribbling down a class diagram) prevents you from doing TDD? That sounds just plain wrong. –  Bjarke Freund-Hansen Jan 24 '11 at 14:10
1  
@bjarkef: Read my answer again please. If the design is final, you cannot really use TDD to drive out the design, which is what TDD is about. And I think this is also what makes the OP confused: he has already a solution, and is now trying to write tests for it. "Which tests should I write first, Product or Order". That question isn't really relevant if you write tests first. –  Martin Wickman Jan 24 '11 at 14:23
    
How do you determine the design is final without any tests or production code? Assuming you want to create something that works. –  JeffO Jan 24 '11 at 15:46
    
@Jeff: You can't, obviously. That's one thing TDD can help you with. –  Martin Wickman Jan 24 '11 at 22:00
add comment

Your Answer

 
discard

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