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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have already created C# WPF application and I would like to create test application for same.
I have searched for that on Internet, I have found below test framework :
Nunit
Robot framework
Unit testing
I am confused to select the best test framework for C# WPF application.
Can you please suggest me
Use an accepted pattern such as MVVM to ensure that there’s no business logic in the UI.
Use NUnit or similar to test the business logic.
Don’t bother with automatically testing the view. It should be simple enough so if it looks right, it is right.
I assume your question is about unit test frameworks.
NUnit is well tested and proven to work. I don't know about the other two but there's also Microsoft's one and xUnit. You really should check xUnit out: https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html
It's actually just a matter of preference. Go after the one you feel comfortable with. Test the others and decide. I can recommend you xUnit as I work with it myself. There's no the best.
You don't really need a third-party framework for writing unit test if you don't want to. You could just create a Unit Test Project (Templates->Visual C#->Test->Unit Test Project) using the built-in Visual Studio template.
You would then add a reference to the project where your view model classes are implemented and write unit tests against these:
[TestMethod]
public void SomeTest()
{
var vm = new YourViewModel();
vm.PropertyA = "a";
Assert.IsNotNull(vm.PropertyA);
}
Of course this assumes that you have implemented your application with testability in mind. MVVM is the recommended pattern to use when developing XAML based UI applications. If you haven't learned it yet, you should. MSDN provides a good starting point: https://msdn.microsoft.com/en-us/library/hh848246.aspx.
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 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.
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 8 years ago.
Improve this question
I have planned to implement automated testing for our web application .I want the tool to be open source, test cases should be written in C sharp.
So i choose to use selenium Web-driver and N-unit. I have a set of questions.
Can i only unit testing with this setup? Cannot do function testing?
I'll avoid answering your first question as it's not suited for StackOverflow :)
Can i only unit testing with this setup? Cannot do function testing?
You can use Selenium with a wide range of tasks.
I started off doing unit testing of individual components of our web application.
Then I moved on to functionally testing the end-to-end behavior.
Currently I'm doing massive stress testing with hundreds of concurrent browser sessions.
All using Selenium.
Should i have to write all test cases as methods?
As far as I know (and I don't know a lot), the most flexibility is attained when you conceptualize your testing architecture this way.
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 9 years ago.
Improve this question
I a have a solution containing 25 projects comprised of both C# and managed C++.
I need to test one of the C# project calls but this project is of type "Window application" (Not DLL).
Even though it is a windows application, my requirement is to call only few internal functional calls (Not related to windows form).
I need to create a separate C# test project to call this functionality. Is it possible to do it like this?
Can anyone suggest a way or examples? And one more thing, I cannot modify the existing code.
Is it possible to do it like this?
Yes. Referencing the project you wish to test in a test project is typically how you unit test your code.
Can any one suggest a way or examples?
Create a unit test project, reference the project that contains the code you wish to test, write tests to test the code you wish to test. If you need to refactor the code to make it testable, do so, or see point below.
And one more thing, i don't have any freedom to modify the existing
source code.
In this case, you are going to have to wrap the code in some cleaner interfaces to allow you to test the code.
The book, Working Effectively with Legacy Code by Michael Feathers has some excellent advice on how to get legacy code under test.