Architecture vs TDD
-
I hope somebody can offer me some guidance as I'm a little stuck and not sure what exactly to do. I have a nicely designed system that has utilised a couple of abstract classes which then have concrete classes implementing them. I'm using the base classes to encapsulate functionality that is applicable across the objects but only use the concrete classes in the application with each concrete class being used in a specific way (so that you wouldn't swap one out for the other) I've run into an issue unit testing, trying to use [Moq] as it is unable to mock a class that inherits from an abstract base class where the methods and properties are not virtual. The only way out of the situation is to either create interfaces specific to each of the classes that inherit from the abstract base (which seems pointless to me, since I'd implement an interface, have current concrete class implement the interface and then replace all instances where concrete class was used with interface) or I have to mark the methods and properties of the base class as virtual and cause a performance problem. I don't like either option and wondered if anybody had come across a similar situation and how they had resolved it?
-
I hope somebody can offer me some guidance as I'm a little stuck and not sure what exactly to do. I have a nicely designed system that has utilised a couple of abstract classes which then have concrete classes implementing them. I'm using the base classes to encapsulate functionality that is applicable across the objects but only use the concrete classes in the application with each concrete class being used in a specific way (so that you wouldn't swap one out for the other) I've run into an issue unit testing, trying to use [Moq] as it is unable to mock a class that inherits from an abstract base class where the methods and properties are not virtual. The only way out of the situation is to either create interfaces specific to each of the classes that inherit from the abstract base (which seems pointless to me, since I'd implement an interface, have current concrete class implement the interface and then replace all instances where concrete class was used with interface) or I have to mark the methods and properties of the base class as virtual and cause a performance problem. I don't like either option and wondered if anybody had come across a similar situation and how they had resolved it?
I'm confused by the title, if you had been writing this system using TDD you would not have the issue because you would have designed your classes with testability in mind. Also it's not Architecture vs TDD they aren't conflicting by any means I practice TDD and have found it a good way to design you generally end up with objects that are loosely coupled and because of the code coverage gained you can perform constant refactoring leading to an architecture that evolves more easier
-
I'm confused by the title, if you had been writing this system using TDD you would not have the issue because you would have designed your classes with testability in mind. Also it's not Architecture vs TDD they aren't conflicting by any means I practice TDD and have found it a good way to design you generally end up with objects that are loosely coupled and because of the code coverage gained you can perform constant refactoring leading to an architecture that evolves more easier
The issue I'm having is that I am unable to use the testing technology that is available to enable me to adequately test the system by isolating each layer. To be forced to have to use interfaces where there really is no need has a 'smell' to it. The system wasn't Test Driven Design, it was designed using normal OOP techniques and it is only trying to use Test Driven Development techniques that I have run into problems. I have found one solution and that is TypeMock which will happily mock a class that has an abstract base class the only downside being the cost. Having spent a fair amount of time looking at Mock 'products' it seems to me that for the most part you end up having to sacrifice legitimate design choices or alter code so that it can cause performance penalities (such as marking methods/properties as virtual) in order to be able to test. I haven't come up with any answers and am more than happy to hear other peoples opinions about this.
-
The issue I'm having is that I am unable to use the testing technology that is available to enable me to adequately test the system by isolating each layer. To be forced to have to use interfaces where there really is no need has a 'smell' to it. The system wasn't Test Driven Design, it was designed using normal OOP techniques and it is only trying to use Test Driven Development techniques that I have run into problems. I have found one solution and that is TypeMock which will happily mock a class that has an abstract base class the only downside being the cost. Having spent a fair amount of time looking at Mock 'products' it seems to me that for the most part you end up having to sacrifice legitimate design choices or alter code so that it can cause performance penalities (such as marking methods/properties as virtual) in order to be able to test. I haven't come up with any answers and am more than happy to hear other peoples opinions about this.
Mock objects are designed to be used up front. Attempting to apply them at the end of a development is pretty much a futile issue.
Deja View - the feeling that you've seen this post before.
-
Mock objects are designed to be used up front. Attempting to apply them at the end of a development is pretty much a futile issue.
Deja View - the feeling that you've seen this post before.
Can you please elaborate on why? In a well designed system with good separation of concerns it should be easy to use Mock objects, is it not simply that generally the technology we have in .Net to support mock objects is not up to the task?
-
Can you please elaborate on why? In a well designed system with good separation of concerns it should be easy to use Mock objects, is it not simply that generally the technology we have in .Net to support mock objects is not up to the task?
Lowest of the Low wrote:
In a well designed system with good separation of concerns it should be easy to use Mock objects,
Well - if you've used techniques such as Inversion of Control then, yes, Mock objects should be fairly easy to use. However, most systems are developed against timescales where good practices like this go out the window. Those that don't tend to have been developed with TDD up front, so the actual mocking has been done well beforehand.
Deja View - the feeling that you've seen this post before.
-
I hope somebody can offer me some guidance as I'm a little stuck and not sure what exactly to do. I have a nicely designed system that has utilised a couple of abstract classes which then have concrete classes implementing them. I'm using the base classes to encapsulate functionality that is applicable across the objects but only use the concrete classes in the application with each concrete class being used in a specific way (so that you wouldn't swap one out for the other) I've run into an issue unit testing, trying to use [Moq] as it is unable to mock a class that inherits from an abstract base class where the methods and properties are not virtual. The only way out of the situation is to either create interfaces specific to each of the classes that inherit from the abstract base (which seems pointless to me, since I'd implement an interface, have current concrete class implement the interface and then replace all instances where concrete class was used with interface) or I have to mark the methods and properties of the base class as virtual and cause a performance problem. I don't like either option and wondered if anybody had come across a similar situation and how they had resolved it?
Lowest of the Low wrote:
or I have to mark the methods and properties of the base class as virtual and cause a performance problem.
What kind of application are you building? I'm willing to bet money that you will not notice any difference at all if you go virtual unless you are building some extremely processor intensive algorithm stuff. Anyway, there are other mock frameworks that allow you to do what you want. (eg, Typemock , but that one is commercial) There are also two kinds of mock usage: 1) You use the mock as a stub just to return test data for you. Eg, you want your DAL class to return some dummy list of customers to your business layer. 2) You do interaction tests, you want to see that classes communicate correctly. Eg, you might want to test that a business class calls your logger class under certain conditions. (http://martinfowler.com/articles/mocksArentStubs.html) The first case is is easy to do with mockframeworks that requires virtual or interfaces. Since if you need a stub you need to create some sort of interface anyway.. So in this aspect Pete is completely right. In the 2nd case, you want to make sure that a certain call flow occurss under a certain condition. In this case you do need to have actual code that interacts, and the mock framework should simply ensure that certain methods were or were not called. This can also be done with virtual/iface mocks, but they are not always enough, eg, they can not ensure that a static method was called. So in this aspect you are better off using a mock framework that can intercept any type of call. (One could argue that static methods are ugly and you should design your api so that you do not need to test if a static/private/non virtual method was called, but that is a whole different story :-) )
-
Lowest of the Low wrote:
or I have to mark the methods and properties of the base class as virtual and cause a performance problem.
What kind of application are you building? I'm willing to bet money that you will not notice any difference at all if you go virtual unless you are building some extremely processor intensive algorithm stuff. Anyway, there are other mock frameworks that allow you to do what you want. (eg, Typemock , but that one is commercial) There are also two kinds of mock usage: 1) You use the mock as a stub just to return test data for you. Eg, you want your DAL class to return some dummy list of customers to your business layer. 2) You do interaction tests, you want to see that classes communicate correctly. Eg, you might want to test that a business class calls your logger class under certain conditions. (http://martinfowler.com/articles/mocksArentStubs.html) The first case is is easy to do with mockframeworks that requires virtual or interfaces. Since if you need a stub you need to create some sort of interface anyway.. So in this aspect Pete is completely right. In the 2nd case, you want to make sure that a certain call flow occurss under a certain condition. In this case you do need to have actual code that interacts, and the mock framework should simply ensure that certain methods were or were not called. This can also be done with virtual/iface mocks, but they are not always enough, eg, they can not ensure that a static method was called. So in this aspect you are better off using a mock framework that can intercept any type of call. (One could argue that static methods are ugly and you should design your api so that you do not need to test if a static/private/non virtual method was called, but that is a whole different story :-) )
The application is fairly standard, its a web application broken down into 3 layers Presentation, Business Logic and DataAccess. Within the data access layer we have an abstract base class that encapsulates standard db access and then we have concrete classes to encapsulate the data access for different parts of the application to different databases. Within the Business logic layer a class will use a specific concrete classes to perform their data access. Inside the business logic layer we have an abstract class that again encapsulates standard functionality used by the concrete classes representing entities. I'm only using mock objects in relation to testing the business logic layer and am using a mixture of the 2 types of mock you describe (not in the same test). I have been using the community edition of TypeMock and it does exactly what I want but the problem is that I am unable to use code coverage inside VSTS with the community edition and it is doubtful that the company will pay for the licence which is why I have had to look into other Mock frameworks which has lead me to run into the issue of not being able to mock. In relation to your type 1 mock how would you go about using an interface when the class you are attempting to mock is unique within the app? Or am I just being dense here and you would simply replace the class interface with an explict interface and implement that in the class? Even if you do this it just 'feels' wrong having to create interfaces where a concrete class would work (from an application point of view) I would value your thoughts.
-
The application is fairly standard, its a web application broken down into 3 layers Presentation, Business Logic and DataAccess. Within the data access layer we have an abstract base class that encapsulates standard db access and then we have concrete classes to encapsulate the data access for different parts of the application to different databases. Within the Business logic layer a class will use a specific concrete classes to perform their data access. Inside the business logic layer we have an abstract class that again encapsulates standard functionality used by the concrete classes representing entities. I'm only using mock objects in relation to testing the business logic layer and am using a mixture of the 2 types of mock you describe (not in the same test). I have been using the community edition of TypeMock and it does exactly what I want but the problem is that I am unable to use code coverage inside VSTS with the community edition and it is doubtful that the company will pay for the licence which is why I have had to look into other Mock frameworks which has lead me to run into the issue of not being able to mock. In relation to your type 1 mock how would you go about using an interface when the class you are attempting to mock is unique within the app? Or am I just being dense here and you would simply replace the class interface with an explict interface and implement that in the class? Even if you do this it just 'feels' wrong having to create interfaces where a concrete class would work (from an application point of view) I would value your thoughts.
Ok but in such case, you won't suffer from any perf problems at all if you mark your methods/props as virtual The overhead of virtual calls is non existing when you bring html rendering and database access into the picture.
Lowest of the Low wrote:
In relation to your type 1 mock how would you go about using an interface when the class you are attempting to mock is unique within the app? Or am I just being dense here and you would simply replace the class interface with an explict interface and implement that in the class? Even if you do this it just 'feels' wrong having to create interfaces where a concrete class would work (from an application point of view)
Well if you use them as stubs because your concrete class is not yet written (kind of the purpose of stubs) Then you would create an interface, maybe not because the app absolutely needs it in the end, but because _you_ need it to be able to continue to work before the stubbed class is actually implemented... The interfaces adds value in form of testability which make you able to develop faster and you get an app that is easier to maintain, even if they don't add much value inside the executing application itself.
modified on Monday, June 9, 2008 8:01 AM