Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
My class has like 30-40 properties, and I really want to unit test.
But I have to create a moq instance (many of them, with different combinations etc).
Is there an easy way? This is real work!
My class can't be refactored, "trust me" (hehe, no really it can't, they are just properties of the object that are very tightly coupled).
Sounds like you need to do some major refactoring. I would start by taking a good look at the single responsibility principle, and making classes that will only have 1 reason to change. Once you break out functionality into separate classes that deal with only 1 responsibility, you can start writing tests for those classes, and they shouldn't take a page-full of mock objects.
This is the advantage of test-driven development -- you immediately run into the problems caused by huge classes, and are driven to avoid them if you want to be able to write tests.
Personally, I don't think you need to try every combination to test your class.
You mention lots about properties, but little about behavior. Shouldn't the tests be about behavior more than state?
There could well be situations where, due to the nature of the class, there are a lot of legitimate properties. I know, I've been there and done that. When examining that class, it is important to determine that each property really does belong in the one class, and not elsewhere. Single Responsibility Principle comes in play here.
Unfortunately, to break any tight coupling, it will take some time and effort to refactor. Just suck it up and get 'er done!
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 1 year ago.
Improve this question
We all know that interfaces and abstract classes are needed for many design principles, and were told to be "the best practice" of programming, both for maintenance and expansion purposes.
But I also heard people saying, "Do NOT overuse interfaces or abstract classes"!
So then, how do I "draw the line"?
I know the difference between interface and abstract class (kind of).
So I'm not interested in "when to use which?", I'm interested in "when is too much"?
For example, the example given by r/PiggyChu620 from this post is clearly "overengineering" the interfaces, as r/AlarmedSlide1 down below puts it.
So to avoid the same mistake r/PiggyChu620 did, is there any "borderline guideline" as to "when should I use interface/abstract class and when should I not"?
Thank you very much for your help!
It's actually pretty easy.
If you can delete an interface from your code (maybe replace it with a specific class when it's used as a parameter) and your code still works, it wasn't needed.
As with every tool, the answer to the question "when should I use it" is "when you need too". If you use it "just because", then you probably make your program simpler (and therefor more maintainable) when you don't use it at all.
Interfaces, Base classes and OOP are important because you are solving problems with it. If you find yourself doing it without solving an actual problem with it, I would consider it "overused".
Interfaces are contracts that are signed between classes, and all classes that use it are bound by the rules of the interface.
This type of design makes it easier to reuse and increases maintenance.
Suppose you create a vehicle interface. All vehicles must implement this interface, including bicycles, motorcycles, cars, etc.
This style of design creates blood and creates a beautiful and principled architecture for your program
So if you have classes that behave similarly, you can use interfaces or abstract classes.
You can refer to this link to compare abstract classes and interfaces
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 3 years ago.
Improve this question
Lets say we have a Service with other servcies on DI. The method under test does somehting with the input data, does some validations, calls a couple of these injected services (can get data only or modify data and then return something) and then returns something.
Given this scenario, I need to write many cases testing all possible behaviors, like validations exceptions, not found exceptions, business exceptions, normal flow, etc...
The problem is that I need to mock all the methods on an injected service for the setup. This could grow fast.
What's the best approach for fixtures and setups (mocking dependencies) in this large/complex method? Is there a pattern that solves this?
For data mocking I use builder pattern wich simplifies the task very well.
You should try create independent classes, which you could test without introducing too many dependencies, but in some point there will be a class which uses other components(for example ViewModel). In such cases I use:
https://github.com/AutoFixture/AutoFixture
It helps in creation system/class under test and helps with injecting dependencies. You can use it with NSubstitute but not only with it.
Using AutoFixture you can create mock classes which you will examine, but rest dependencies which will be not needed AutoFixture will auto-generate for you, so extending a constructor will not lead to modifying bunch of unit tests.
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 4 years ago.
Improve this question
I have inherited a very old (first commits are in 1999) code base and have found 500 of the 2000 or so unit tests to be failing. My question is, should I go through each test manually and check if it is still relevant or should I start over?
Nobody here can answer this as such, but you have to ask for each test:
Does this test still make sense? If not, remove it.
Is the test testing something that should work? Do something to fix it up.
Is the test conceptually useful, but what it tests has changed so it is now failing? Rewrite it so that it works in its new way.
How much effort to fix vs. value is the test? If it's a lot of effort, and low value, maybe remove it...
We can't really say whether you should do one thing or another.
It's probably worth just LOOKING at the tests, and especially looking at the effort of fixing the test before starting any real work.
You may also need to consult with some kind of test-manager for your group, and seek their input to the coverage/bug rate/common problems, etc for that part of the code.
When I look at old tests in our code base, it's sometimes best to remove, sometimes worth "fixing up" and sometimes worth starting from scratch. Unless you are familiar with the test, it's hard to say before you spend some effort on investigating the issue...
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 2 years ago.
Improve this question
I am working for a consulting company that develops a lot of Add-Ons for SAP Business One using .NET. I want to introduce TDD (or at least some good unit testing practices) to the company to increase code quality. Here's the problem.
SAP provides a COM object (called Company) that lets you interact with the data in SAP. Company is an interface, so it can be mocked, but the amount of Mocking that would have to be done to get a single test to run is huge! I've tried it out with a few tests, and although they work, I really had to have a good understanding of the internals of the unit that I was testing, in order to create tests that passed. I feel that this very much defeats the purpose of the unit tests (I'm testing the internals as opposed to the interface).
Currently, through the use of dependency injection, I've created a Mock Company object that returns some Mock Documents that will sometimes return Mock values based on different circumstances, just to get the tests to run. Is there a better way? Has anyone been able to effectively unit test code that heavily depends on some external library? Especially when the results of the tests should be some change to that mocked object? (Say, when the add-on runs, the Mock Company object's SaveDocument function should be called with this Mock document).
I know this may be a strange question, but the fact of the matter is that in order to get these unit tests to run well, I feel like the only option to me is to create a really...reaally large mock that handles multiple Mock Documents, knows when to give the documents at the right time, and a lot of other things. It'd be essentially mocking out all of SAP. I don't know if there's some other best practice that others do in these cases.
Thanks in advance!
EDIT: Carl Manaster:
You're probably right. I think the problem is that most of the existing code base is very procedural. A lot of Windows services with a Run() method. I can definitely see how, if the project was structured a bit better, tests could be made with a lot more ease.
But let's say that the company can't invest in refactoring all of these existing projects. Should I just abandon the idea of unit testing these things?
If your methods are short enough, you should be able to mock only the interactions with one entity (Company), without interacting with the entities it returns. What you need is for your method to call (let's say) company.getDocument(). If your method under test has further interactions with the returned document at that point, split out that code, so that you can test that code's interactions with a (mocked) Document, without worrying about the Company in that test. It sounds as though your methods are currently much too long and involved for this kind of approach, but if you whittle away at them to the point where testing one method simply verifies that company.getDocument was called, you will find it much easier to test, much easier to work with, and ultimately much easier to understand.
Update
To your question of whether you should abandon the idea of unit testing: Do you want it to work? Do you have changes to make to the code? If the answers are (as I would assume) affirmative, then you should probably persevere. You don't have to test everything - but test what you're changing. You don't have to refactor everything - but refactor what you're working on so it's easier to test and easier to change. That "whittling away" that I mentioned: do that in service of solving the problems you have at the moment with your code base; over time you will find the code that most needed the tests has been tested - and it's a lot easier to work with because it's well tested and better factored.
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 6 years ago.
Improve this question
I have pretty much finished my first WPF project after several weeks.
Now I want to refactor and make my application as clear / reusable as possible.
Does it take a lot of work (meaning would certain logic change entirely?) to change an entire application to the MVVM pattern and would it make the application easier to understand? Also are there other things I should look into except for MVVM?
Basically this application will be used by someone other than myself, so my goal is to make this program more simple since it really got over complicated in certain areas.
The general layout of my program consists of:
10 Classes (1 database class using Singleton)
3 HelperClasses
3 UserControlPages
Singleton in about 3 classes
Does it take a lot of work to change an entire application ?
It's hard to say, cause it depends on the concrete project and how it was coded before, but basically it's never a small amount of work.
would it make the application easier to understand?
Would say: no, but it would definitely make it more testable and more scalable.
Also are there other things I should look into except for MVVM?
It, again, depends on the concrete project (what is target client of your project, who will reuse your code, what is the expected scale of your project...)
Bare in mind that using the MVVM pattern requires a framework, otherwise it is a huge amount of work. I would recommend Caliburn.Micro, and you should investigate the other frameworks available too.
Refactoring effort will depend upon existing code. If you have loose coupling in mind right from start, it should not take much effort.
Following are links to questions related to getting started with MVVM.
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
https://stackoverflow.com/questions/2267903/learning-mvvm-for-wpf
If you have any specific question, update the question to mention it.