I have created one web application which includes login page and several other pages which include input controls.How i can perform Nunit testing on this pages.
It will be very helpful if you provide guideline for just only login page.
Login page is created using Login.aspx and Login.aspx.cs file.
It is not created using MVC.
You are confusing unit testing with automated UI testing. NUnit, as its name states is for creating automated tests for separated pieces of code. With this tests you check if concrete piece of code does what it should do. To check this you substitute all its dependencies (all classes/interfaces it interacts with) with stubs/mocks (more) which place the role of placeholders for real functionality. Thanks to this you can check if tested class behaves the way you expect it to behave because you have full control over its dependencies, so the only "unknown behavior" comes from object under test.
If you, however would like to automatize tests of user interface you can use special environments dedicated for this task. You can easily find dozens of frameworks for this, one of which is FitNess
Related
I have a situation where feature-toggling is implemented in an application and I want to have automated Selenium tests that are in place for both states of the application. (Both states are possible in a production state.) The tests that are executed would be based on the feature-toggling configuration that is present in the web application.
In a normal situation, using "Scenario Outline" will result in a generated test that can be executed via Test Explorer, and the CI process for an application can be configured to execute all of the tests that are part of the test assembly after it is built. In my situation, an application state could cause one test to pass and another test to fail (think lack of UI controls because of a feature state). I looked into hooks and I see that there is a BeforeScenario tag, but I don't think this gets me what I'm wanting to achieve so much as it allows me to do some setup before a scenario executes.
I usually include a step that sets the scenario to "pending".
Scenario: Some new feature
Given pending story 123
Given condition
When action that includes new feature
Then something
The step definition for Given pending story 123 would call:
Assert.Inconclusive($"Pending story {storyNumber} (https://dev.azure.com/company/project/workitems/edit/{storyNumber})");
This marks the test inconclusive when using MS Test. We use Jenkins for continuous integration, and our builds continue passing. It's also handy because I can provide a link to the story or feature in something like Azure DevOps, GitHub, Jira or their ilk.
This is not exactly a feature toggle, but it is easy to remove or comment out the Given pending line of a scenario in your topic branch to enable the test.
There is need to create small scale winform applications for private use by my company for interaction with our database. Period. I know that .NET MVC has a very mature unit testing framework for the MVC pattern as I want to do TDD.
Thus, is it possible to use NUnit or some other easy/mature unit testing framework (EDIT: Based on my experience with ASP.NET) with the following tutorial given here? I have googled and checked my technical book library, and there is a distinct lack of documentation for how to do effective unit testing for winforms. Thus, I am turning to this forum hoping individuals can share their domain knowledge with me.
The most I have found has recommended the MVC pattern (which I agree with), but not how to address specific issues with the winform. For example, how do I test a button click and subsequent action by that button?
I plan on using C# VS13 .NET 4.5. I am excited to join this resource and will contribute rep to all who answer my inquiry. Thanks.
As you have probably noticed, the idea there is to have your view described with an interface.
Thus, the controller doesn't really need a window, it needs a class implementing the interface.
And thus, you could have yet another, auto-mocked or manual implementation of the view interface that doesn't involve the WinForms subsystem but rather, exposes the data to write your assertios.
Having your stub view, you just write a script against it. You expose some methods from the class that allow you to automate the interaction:
public class ViewStub : IView
{
// implement the view interface as it is but also
// an extra stuff to let you automate this in your unit tests
public void RaiseButtonClick()
{
this.controller.DoTheButtonClickStuff();
}
}
Then your test becomes (I follow the convention from the tutorial)
ViewStub form = new ViewStub();
IModel mdl = new IncModel();
IController cnt = new IncController(view,mdl);
form.RaiseButtonClick();
Unit Testing a GUI is something that is independent of the GUI library used. The answer to the general case answers your case as well:
How can I unit test a GUI?
Unit testing a GUI is done by minimizing the footprint of classes that do depend on your GUI framework. Then the classes that still depend on the GUI framework are not unit tested (which is not at all the same as "are not tested"). Those classes are the "View" in patterns like MVP, MVC, MVVM.
Conclusion: Every good .Net Unit Testing framework is a good WinForms Unit Testing framework. One example of such a framework is NUnit, which you mentioned in your question.
Unit testing is not inteded for UI. Of course you can do it, but I don' recommend it for few reasons: You cannot unit test DPI changes, multiple screen, how your program acts in different window states or what happens if user moves with tabulator between your controls. Unit testing UI will only give you false safety.
Use UI automation tools to test UI automatically if you want to, but leave the unit testing out of it. You can keep the UI layer thin as possible and this is also a good design practice. You can use unit testing for other classes which are used in your winforms app.
I wondered if anyone had links or comments on strategy as regards to testing a webforms application, I am referring specifically to automated testing practices, and unit testing.
My current strategy has been to separate business logic into a separate DLL that can be Unit tested on a class by class basis. However when it comes to testing the web Forms themselves using code UI tests, it appears I should be running two instances of visual studio 2010, one for the application and the other in order to run the created UI tests.
I found this link:
Testing ASP.NET webforms applications
However while this link was interesting it does not answer my question with regard to a strategy on a green fields project.
Although MVC3 would solve some of this, part of my reason for sticking with webforms is that I am slowly migrating aspects of a legacy system and to start from scratch on everything, when I can migrate strategic parts does not make sense.
Any links comments or observations would be welcome. Thanks.
1 You can try with Selenium if you want just test your interfaces
http://seleniumhq.org/
2 On functionnal subject (Code behind) It's very difficult to test because you must mock your pipeline, when i compare to MVC.
So for example you can mock HttpContextBase
var mock = new Mock<HttpContextBase>();
I'm a C# and UI developer and I'm interested in writing unit tests in VS CodedUI for ASP.NET web applications. Most of the usages I've seen are integration tests, in that you write a test that points at the actual web page, run through some steps and test the output. I want something smaller and more granular, that is super simple for developers (read: lazy :P) to write.
My current setup looks like:
Web application, containing pages, controls, javascript, etc.
The web app also contains test pages - pages that contain a single user control in the markup, and some hard-coded data in the code-behind.
A CodedUI project that launches the test page, runs the test and asserts the output.
This is a nice start, but I'm looking to improve it.
The (first...) problem is that the test data and the test steps are in different locations - on the web app and codedUI project respectively. In regular developer unit tests, you write code that sets the data, then you do everything else, and everything you need is in one location. With my setup, a person looking at a test failure has to know to look at both the test and the page being tested.
A few ideas I had, and why they suck:
Put the test page in the codedUI project. This is a problem for a few reasons. User controls can't be easily tested, was my stopping point, but I believe there are plenty of others.
Pass in a query-string to the test page that provides the data. This isn't a terrible idea, but it might get unwieldy quickly.
Pass in a public class to be loaded by the test page which contains the test data. This requires the test page to have a reference to the testing project, which is no good.
Dynamically write and compile a test page in the codedUI test. I don't even want to start with this.
I suppose you are talking about unit testing your web pages with external data. With CUIT, you can do that with data driven CUIT.
I seem to be having an issue, the application we're using uses a Ninject kernel, and contains a particular configuration that's gathered with contents of the WCF call (username, token...).
Based on that a particular configuration the user is assigned rights on the app, this is shielded through a particular instance in the Ninject kernel.
We cannot just recompose the Ninject kernel, what we'd like to do is run a couple of Nunit tests, but run each of them in a separate app domain (recreating the kernel each time with different settings).
I've only found ways to run whole test projects in different app domains but not test per test.
Is there a way to solve this?
Unfortunately the Ninject configuration is not on our side, we have to 'live' with it this way.
I needed to do the the exact same thing, so I created a library which basically takes the current test and re-executes it in a new AppDomain. It's a nuget package called NUnit.ApplicationDomain and is open source.
Example Code:
[Test, RunInApplicationDomain]
public void Method()
{
Console.WriteLine("I'm in a different AppDomain")
}
I don't think there is a way to solve it without re-writing parts of the NUnit code. It has been a while since I've been inside the NUnit code, but I am pretty sure the main app domain loading part has not changed.
NUnit typically uses two app domains. The default one that is created when NUnit is run and a separate one to load the test assemblies and the assemblies they reference. It's main reason in doing this is to allow the unloading of the test assemblies. You can't unload a dll, but you can unload an appdomain.
You might be able to run NUnit once per test and pass the test on the command line, but that's ugly and I'm not sure it will help.
It might also be possible to leverage Action Attributes in NUnit 2.6, but you are going to do a lot of work in there to do it.
You might also be able to create a new app domain in your setup method and call into it in each test. Awkward but possible.
I'm sorry I don't have a more complete answer.
I'm not entirely sure about your question. However it seems like you need some kind of a custom implementation. Did you consider custom test attributes? Then may be configure each attribute to run in a different App Domain? I'm just spinning up some ideas, but there may be better ways of doing this.