locked
TDD and MVC RRS feed

  • Question

  • I'm using TDD for a large project I'm planning, but whenever I research into TDD, the MVC pattern is always mentioned. Is it a best practise to use TDD with MVC? What if I just use TDD with the ntier approach? I'm currently working on an ASP.NET web app.

    Thanks
    Wednesday, February 27, 2008 12:08 AM

Answers

  • Hi,

     

    They're completely seperate techniques, although it's likely that TDD would lead to an MVC type pattern for the implementation. 

    Due to the fact that TDD evolves loosely coupled designs with interfaces to everything, it is entirely possible that you will end up with an MVC / MVP pattern in your code. 

    Since you're asking about it, it would appear that you're not aware of what they are, or how they work.  I would recommend reading up on design patterns, such as MVP and others, so that when the design evolves you can implement a tried and tested approach, one that you can apply a name to so others also understand, rather than leaving it to chance or luck.

     

    Take a look at:

     

    http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

     

    www.dofactory.com

     

    for design pattern related information.

     

    To make TDD work properly for you, I would recommend you reading up on mock objects, and how they work.  In this way, you will force yourself to use interfaces and will be forced to understand the code.

     

    MVP, or MVC is an approach to implementing the software, and you would probably consider it 'best practice'.  n-Tier is another approach that in certain scenarios could be considered 'best practice' also.  Neither of these practices counts out the use of TDD to evolve the designs. 

    One thing that slightly worries me is how well you understand TDD, make sure that you don't try to use TDD, and plan to any level of detail with designs, as you will find it difficult.  TDD is about working from a test, or requirement, and evolving a design to fit that.  If you try to implement a design then test, that's not TDD.  If on the other hand your requirements, and hence tests are consistent in both approaches, you should come out with the same result.  My opinion would be that it is a good idea to have a list of intial tests to start with an a conceptual model of what you want to do perhaps, then use TDD to evolve the rest.

     

    I hope this helps,

     

    Martin Platt.

    Wednesday, February 27, 2008 12:49 AM

All replies

  • Hi,

     

    They're completely seperate techniques, although it's likely that TDD would lead to an MVC type pattern for the implementation. 

    Due to the fact that TDD evolves loosely coupled designs with interfaces to everything, it is entirely possible that you will end up with an MVC / MVP pattern in your code. 

    Since you're asking about it, it would appear that you're not aware of what they are, or how they work.  I would recommend reading up on design patterns, such as MVP and others, so that when the design evolves you can implement a tried and tested approach, one that you can apply a name to so others also understand, rather than leaving it to chance or luck.

     

    Take a look at:

     

    http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

     

    www.dofactory.com

     

    for design pattern related information.

     

    To make TDD work properly for you, I would recommend you reading up on mock objects, and how they work.  In this way, you will force yourself to use interfaces and will be forced to understand the code.

     

    MVP, or MVC is an approach to implementing the software, and you would probably consider it 'best practice'.  n-Tier is another approach that in certain scenarios could be considered 'best practice' also.  Neither of these practices counts out the use of TDD to evolve the designs. 

    One thing that slightly worries me is how well you understand TDD, make sure that you don't try to use TDD, and plan to any level of detail with designs, as you will find it difficult.  TDD is about working from a test, or requirement, and evolving a design to fit that.  If you try to implement a design then test, that's not TDD.  If on the other hand your requirements, and hence tests are consistent in both approaches, you should come out with the same result.  My opinion would be that it is a good idea to have a list of intial tests to start with an a conceptual model of what you want to do perhaps, then use TDD to evolve the rest.

     

    I hope this helps,

     

    Martin Platt.

    Wednesday, February 27, 2008 12:49 AM
  • Very detailed response.

    At the moment I am doing reading on TDD. I also have the C# design patterns book but I am yet to begin reading through that.

    So because of this I know how TDD works. The only thing I need to understand is mock objects and then I should be good to go. I have the tools (nunit) and will get TDD.NET.

    As for how TDD works, I am aware of that. Unit testing is usually write the code, then test it.

    The only thing I'm wondering is how do I test the conditions? For example, I write code that makes a random string of characters with a blur for a captcha control but how can I write a test case for this and then see if it passes (after writing the code)? How will it see if the characters are written?

    The other thing which I'm wondering is interfaces. In my web app I will need to call external functionality (or basically functions in classes). Is it bad practise to make a direct function call? Should I just write the interface for a piece of functionality and then implement it in the codebehind of a page? So basically, the other thing I'm wondering (which could be asked on ASP.NET forums) is how should I call a function?

    Thanks



    Wednesday, February 27, 2008 3:38 PM
  • TDD isn't about writing code then testing it, I hope you didn't mean that?!  Purists in TDD will writer the code, make it fail, write the code to pass, refactor.  Keep going like that.  If you do it the other way around, the code will need to be refactored to make it testable, or quite probably will, that is why the test comes first.

     

    Mocking objects is the answer to your question - the captcha control - you would be testing the flows through the logic that does the blurring.  Difficult to explain, but basically you inject a mocked interface or interfaces into the object constructor, then expect that certain methods are called, properties are accessed or set.  That way you are testing the path through your code.  If the path through the code is taken and all the tests pass then, your code works for those tests.  If you had all the tests that you could possibly need, and they all passed, hypothetically then you coudl be 100% confident that the code works, the challenge is in getting the right tests!

     

    If you're using TDD you won't be able to test, unless you use interfaces, since the interfaces are what is mocked.  There are mocking frameworks that allow you to use class mocking, but personally I think that leads coupled code, and so should be done properly with interfaces.  Good OO designs should always use interfaces. 

     

    In terms of calling code in the code behind, yes I would always use interfaces.  In terms of the code behind, I would be using an MVP pattern, and that would call to a business layer through an interface, to do the work.  The interface code behind would only have code to raise exceptions on the view interface of the MVP, and have methods to get the interface to "SetPersonName" or operations of that sort.  If you did all the work in the code behind, it would be incredibly difficult to test, and you wouldn't not be able to do TDD.  If you use an MVP pattern, that calls business logic code, both the presenter and the business logic code would be testable, and the only very thin part that could not easily be tested would be the small interface implementation that raises events on the view interface, and sets values into controls.

     

    The testing of the interface could them possibly be tackled using some automated testing techniques, but since there would already be unit tests for everything, those tests should only be testing the thin UI layer, so failures should be easily isolated, and not require hours of debugging.

     

    I hope this helps set you off on the right path,

     

    Good luck,

     

    Martin Platt.

     

    Thursday, February 28, 2008 12:50 AM
  •  Martin Platt wrote:

    TDD isn't about writing code then testing it, I hope you didn't mean that?! 



    Sorry I didn't mean that. I meant you write the test, it fails as there is no code, then write the code for it to pass.


    Purists in TDD will writer the code, make it fail, write the code to pass, refactor.  Keep going like that.  If you do it the other way around, the code will need to be refactored to make it testable, or quite probably will, that is why the test comes first.

     

    Mocking objects is the answer to your question - the captcha control - you would be testing the flows through the logic that does the blurring.  Difficult to explain, but basically you inject a mocked interface or interfaces into the object constructor, then expect that certain methods are called, properties are accessed or set.  That way you are testing the path through your code.  If the path through the code is taken and all the tests pass then, your code works for those tests.  If you had all the tests that you could possibly need, and they all passed, hypothetically then you coudl be 100% confident that the code works, the challenge is in getting the right tests!



    Is there an example of this?

     

    If you're using TDD you won't be able to test, unless you use interfaces, since the interfaces are what is mocked.  There are mocking frameworks that allow you to use class mocking, but personally I think that leads coupled code, and so should be done properly with interfaces.  Good OO designs should always use interfaces. 

     

    In terms of calling code in the code behind, yes I would always use interfaces.  In terms of the code behind, I would be using an MVP pattern, and that would call to a business layer through an interface, to do the work.  The interface code behind would only have code to raise exceptions on the view interface of the MVP, and have methods to get the interface to "SetPersonName" or operations of that sort.  If you did all the work in the code behind, it would be incredibly difficult to test, and you wouldn't not be able to do TDD.  If you use an MVP pattern, that calls business logic code, both the presenter and the business logic code would be testable, and the only very thin part that could not easily be tested would be the small interface implementation that raises events on the view interface, and sets values into controls.

     


    From this paragraph it makes a strong case for the ASP.NET MVC pattern. So a function call is a bad practise? Anything remotely known to be a bad practise I want to avoid.


    The testing of the interface could them possibly be tackled using some automated testing techniques, but since there would already be unit tests for everything, those tests should only be testing the thin UI layer, so failures should be easily isolated, and not require hours of debugging.



    Seems like TDD and MVC will reduce debugging time and that is something which I find very attractive.

     

    I hope this helps set you off on the right path,

     

    Good luck,

     

    Martin Platt.



    Thanks!

     

    Thursday, February 28, 2008 11:14 PM
  • Also, if I am not using the MVC approach but using TDD, how would I write functionality such as a captcha control and implement into the page?
    Friday, February 29, 2008 3:32 PM
  •  

    If you're using it properly, using TDD will evolve a design at least similar in many ways to the MVC / MVP architecture.

     

    TDD requires, or should require that you access things through interfaces, and that you can inject dependencies, which are two distinct features of the MVC/P pattern.

     

    I don't know how to answer your question, what did you mean with the question as to how you would write the functionality without using such a pattern?  Perhaps you could be more specific with what you're wanting?  There are many ways to do this, but if you were not using MVP patterns for your control, you would have to at least make sure that the controlling code implements an interface, and allows dependency injection.  How you would do that would really be down to what you're trying to achieve.

     

    I hope this helps,

     

    Martin Platt.

    Monday, March 3, 2008 4:15 AM
  •  Martin Platt wrote:

     

    If you're using it properly, using TDD will evolve a design at least similar in many ways to the MVC / MVP architecture.

     

    TDD requires, or should require that you access things through interfaces, and that you can inject dependencies, which are two distinct features of the MVC/P pattern.

     

    I don't know how to answer your question, what did you mean with the question as to how you would write the functionality without using such a pattern?  Perhaps you could be more specific with what you're wanting?  There are many ways to do this, but if you were not using MVP patterns for your control, you would have to at least make sure that the controlling code implements an interface, and allows dependency injection.  How you would do that would really be down to what you're trying to achieve.

     

    I hope this helps,

     

    Martin Platt.



    Hi,

    The question about writing the functionality without using the MVC pattern is irrelevant now.

    During the period of my last post and your reply, I thought about TDD and the fact I'll be using a design reliant on interfaces (no bad thing) which meant that whatever I do, if I use TDD I'm going in the direction of the MVC framework so there is no point in trying to change the inevitable. Smile


    In the end, I will be using MVC and now I understand some things I was sketchy on. Furthermore, the same web app can use the standard ASP.NET model and MVC. The only thing which put me off and may show in the above posts is that the MVC framework still lacks some features, which will be fixed.


    Thanks!
    Monday, March 3, 2008 11:07 PM
  • Hi,

     

    That's good that you realise if you do things properly with TDD you will end up with an MVC / MVP like design.  I was talking about a pattern though, the MVC or MVP pattern rather than the ASP.NET MVC guidance package.  I hadn't twigged that that was what you were referring to.

     

    In terms of whether you should use the guidance package, will come down to how confident you are that you can do what you need to with it, and it allows you to work around, or otherwise implement the solution that need to.

     

    If you can't, then get onto the net, and look at MVP patterns, and do it yourself, it would be a good learning exercise at the very least.

     

    I haven't used the guidance package, so I can't comment on how well it will work for you, I am afraid.

     

    You certainly won't evolve an MVC guidance package from TDD, since those sorts of things are meant to be ultimately configurable and everything to everyone, which is against the idea of TDD.  Which comes down to implementing only what you need, and nothing more, and the acronym YAGNI comes to mind here, "You aint going to need it".  There's no reason why you shouldn't use the guidance package, however, it will probably be quite difficult to get into using TDD with it, as it is already existing, so you'd need to know that you could either use already defined interfaces, or wrap your own around existing functionality.  It's doable, but the experience will be harder especially if it's your first propert shot at TDDing.

     

    Good luck,

     

    Martin Platt.

    Monday, March 3, 2008 11:56 PM