I'd like to view the tests in Test Explorer by class, but when I do so, even the ones that failed get hidden under the class categories, so I have to manually expand them all. I wind up just viewing them by status (pass/fail), but then they get all mushed together in one big long list. Is there any way to expand all the categories at once?
Not possible unfortunately . You have to manually go and check them. But the test view by resharper gives a better overview.
Here you can see all the failed tests by number. Clicking on the failed tests tab(#67) on top will show just the failed tests (project-wise in this scenario) :
Related
Best way of handling many test cases needing to navigate to a particular place before they run their asserts? For example a process has 5 steps and a test case needs to test a part of step 5, how can I set it up? Call the test case methods of the previous steps inside this test case, and do that for all test cases that test step 5?
Similarly, if a test case goes deep into the website - through many pages - should that navigation be re-written for every test case, or just call some test that already does that?
Any tips on this situations?
Best way of handling many test cases needing to navigate to a particular place before they run their asserts? For example a process has 5 steps and a test case needs to test a part
of step 5, how can I set it up?
I would create a Transporter class / pattern that the test case can call to get to that state. That will make the navigation code reusable to other tests and not make the test too big/complicated. You can also use the setUp() methods in your xUnit testing frameworks which will be called before each test and place the navigator code there, if you need to use it for other tests.
Similarly, if a test case goes deep into the website - through many
pages - should that navigation be re-written for every test case, or
just call some test that already does that?
I would extract that code into a helper class called Transporter and have the tests call it to easily navigate to the deep page in one method call.
I wrote about this and other test design patterns in a conference paper at the Pacific Northwest Software Quality Conference. Look for the Transporter pattern in that paper.
Here's an example using a Transporter class where you have to login and navigate to the checkout page:
public class Transporter {
public static void login() {
//App specific code to navigate to login screen and login to the application
}
public static void gotoCheckout() {
//App specific code to navigate to the checkout page
}
}
Now your tests can just call this Transporter class to do the navigation for them.
If you are using BDD, such as JBehave (not sure if Cucumber has the same feature) where you have the Given, When, Then story (feature) structure in Gherkin syntax, you can actually use "GivenStories" feature which are like prequel test cases to set you up for your specific test case, exactly as you are describing.
There's nothing wrong, however, when using BDD to simply make multiple step scenarios leading up to the particular test case, i.e. first scenario logs-in, second scenario navigates to certain page, third scenario performs your actual test.
By writing it as a separate story (feature), however, you can re-use those as "GivenStories" in JBehave as a shortcut to get where you need to be without duplicating the steps.
New to ember.js -- used http://yoember.com/ to create a Demo ember.js site. I'm trying to figure out how to use Protractor to test certain elements, but I'm encountering issues specifying them.
Most, but not all, elements (buttons, text areas, etc) have a serialized id value: id='ember###' that changes every time the page is reloaded, which makes it impossible to indicate some elements in Protractor (like, element(by.id('ember557')).sendKeys('foo');).
Running a command like the one above will return the error: Failed: No element found using locator: By(css selector, *[id="ember557"]), which is due to the 3-digit id value changing.
In my demo app, I was able to go into the /app/templates/components/ file for that page and manually add something like id='name' into the handlebars input and was able to successfully find and test that element in Protractor.
This isn't ideal though, and I'd like to find a way to test sites that I don't have the ability to modify the html of.
Can anyone help me wrap my head around this? Thanks.
I recently created a VS2015 solution to migrate projects & test projects from VS2010. I am experiencing odd behaviour with one particular test class which has a reference to PostSharp, where the combined namespace and test class name reaches 128 characters (which isn't many in my opinion). The tests show as 'excluded' in the test explorer window (When the tests are grouped by project). Also when I right click within the test class, the output window shows 'No tests found to run'.
When I try to select the test methods within the 'external' node, the following test is displayed: 'Source: no source available'.
I have tried creating another test project in a different solution, and purposely exceeded the 128 characters without postsharp and the problem goes away.
The obvious fix for this is to shorten the length of the namespace, however I am curious as to whether anyone has ever found a reason / solution for this?
I have a component my-component that includes a {{view "select"}} I want to unit test. In the unit test I use moduleFor('my-component') and load the component into the DOM. The error that shows is that Assertion Failed: select must be a subclass of Ember.View which seems to originate from handlebarsGetView(). I stepped through the debugger and noticed that the container doesn't have view:select.
I feel like I'm missing something with the resolver. Why can it not locate the select view? I also tried manually adding view:select in the needs callback for the test but then I get a complaint that it cannot add view:select because it does not exist.
I think you need to use Ember.Select? I recall this one being different for some reason, and I think the core team has plans to overhaul it in the near future.
I'm trying to use Visual Studio's unit test generation feature. The first thing I found was this extension, but for some reason it doesn't work - even after rebooting, though I can verify the extension is installed, "Generate Unit Test" doesn't show up in the context menu when I right-click within a method.
The next thing I tried was a workaround I found in one of the reviews - apparently the original feature still exists, just buried. The workaround is:
Tools->Options
Environment->Keyboard
Show commands containing 'unit'
Attach a shortcut to "EditorContextMenus.CodeWindow.CreateUnitTests".
But that didn't work, either - as in, nothing seems to happen. There are two other commands that may be relevant - EditorContextMenus.CodeWindow.GenerateUnitTests and Project.AddUnitTest. Neither of those work either - the latter just does nothing, the former gives me the error "Controller must have testable element property set up".
So... I'm not really sure what else to try.
I have a same problem, and here is reason why the error occurred.
In the documentation of code generator, the arthor metions an super important pre-requisite.
In the final release we require a public class and at least one public method, before the Generate Unit Test feature lights up.
http://blogs.msdn.com/b/willy-peter_schaub/archive/2013/07/19/exploring-the-unit-test-generator-vs-extension-v1-rc.aspx
From the article, I have found that there is two requirements make the Code Generator works.
The class must be public
At least one public method in the class
You can try to make the Access modifiers to Public to solve the problem
Apparently the extension doesn't work for structs, I found out today - no matter what you do, you get the "Controller must have have testable element property set up" error.