Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing a software in WPF c#. My software has multiple windows. I need to share a same instance of on object across multiple windows (I am using legacy code, so I can not make that object static). Is it a good practice to have a static class which will have variables that I need to share across multiple windows, so I can avoid passing them through a constructor. Thank you
You could either use a static class or you could inject all windows/view models with the same singleton instance. Note that this doesn't necessarily has to be a class that actually implements the singleton design pattern but you need to make sure that you inject the windows/view models with the very same instance.
The latter approach is the preferred one, mainly because a non-static shared class can implement an interface which enables you to easily replace the implementation with another one which in turn makes it a lot easier to unit test your classes.
So it is not, at least in the general case, really a good practice to use a global static class but this might still work in your specific scenario.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you're developing application using the code contracts, you may know, that this concept was introduced in Eiffel programming language.
I have become very confused after trying this concept in my C# application using System.Diagnostics.Contracts.
The main question for me is the next:
Are unit-tests really needed, if you have code contracts?
One of the major differences, that unit-test frameworks usually don't provide, is the possibility to call private methods (except MS fakes library with its shims). It's done, because of supporting composition & the idea, that private methods are covered by public method calls.
As for the code contracts, I can declare Contract.Requires, Contract.Ensures for private methods.
So, why do I need unit-testing, when I have code-contracts, which behavior is very similar.
Thanks
You surely need Unit testing.
With code contracts, you can only have your static contract verification.
There's much more you can do when running your code.
For example, say you are testing a class that depends on IConnectionProvider. What happens when your GetConnection throws? Code contracts won't help you with that.
Ideally you'd be testing the public methods of your class with different inputs, and verifying that it behaves as expected. This will help you find bugs, and in the long run, design better code.
I would say no. By using code contracts you are defining what your code is supposed to do and checking that it is doing it. The unit test does the same thing for the most part so I believe it is redundant to the point that it is not cost effective to write both.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am considering NPoco for a large business application. I am a bit concerned that is it worth to develop a repository pattern?
I will need to handle complex SQL statements and extensive database operations on several entities in a same use case.
NPoco provides a variety of db operations functions, which I think will not be (directly) exposed to the consumer layer(s) by my repository layer.
Edit-1
Which approach is better to get most out of NPoco?
If you want to invest time in unit tests, then the Repository Pattern is worth it. However if most of your application logic is in stored procs and functions, then you will be limited with unit tests and just spend your time in integration testing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Recently I have been asked in an Interview that: "Can you give an example of a situation where is it necessary to break the Inheritance chain?". I am not very sure if I could follow the question exactly.
Does any such situation exist when we to break the inheritance chain?
I tried google, but didn't get any clues.
A. When we get stupid questions that make no sense.
Inheritance is just a tool for managing and re-using code. Composition is a strong tool that is not part of an "inheritance-chain" so I'm guessing that's an answer they're looking for?
Another possible answer they're looking for is utilizing interfaces. As interfaces don't require an "inheritance chain". They enable you to be a little more flexible with your architecture and step away from strict inheritance "chains".
However the question implies that you have a number of objects that all inherit from one another and for some reason you "break" the chain of inheritance somewhere. There is no "set" reason why you'd do this as each implementation of OOP that addresses a problem is typically unique.
The way the interviewer phrased the question makes little to no sense. It's a bad interview question that wont result in the best answers or necessarily tell you anything about a candidate except that they don't understand your madness either ;).
EDIT: added some "better" questions.
Better questions include:
Q. What is the difference between inheritance and composition?
Q. I have the following class model (one crying out for an interface), can I improve it at all?
Q. I'm re-designing a base class and want to prevent other people from overriding this function. Can I do that?
Q. Is there a problem with calling virtual methods in class constructors, if so, what?
There's this blog post with a good explanation on why you'd want to "break the inheritance chain" (or "seal" your class).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have asked a unit testing practical question previously (Unit testing: how to test methods with a lot of underlying objects and business logic), and I need to open another subject on the same piece of code.
The question is what if I disregard what everybody tells me, and I proceed to "unit-test"-ing that MoveElementAtIndex method (which moves Products within a product collection) without any stress about the underlying calls and usages of other classes. I can just instantiate a new collection of products and test that they move around correctly, right?
This is not unit testing, I know. It's not integration testing either.
It's hybrid, and what would you say it is wrong with that? It would still help me to avoid problems. Or wouldn't it?
Nothing very wrong about it, but you could easily make it a real unittest, if your collection was not concrete products, but interfaces of products. By doing this, you make sure, that the outcome of your test does not depend on the implementation issues in your product objects. This makes the test cleaner, and your code more dependable.
And by the way: There are no hybrids between unit and integration tests. What You have is an integration test. Only if you replace all external dependecies with stubs or mocks, you can call it a unit test.