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?
Related
I am using coverage to check which unit tests to write. I'm checking in accounts/views.py, for which I haven't written any tests, but why it's not showing tests missing case(i.e in red)?
I expect around 50+ statements to be in error stage, excluding imports to write tests. But it's like 50% doesn't need any tests!
coverage html for views
The lines in a class statements are executed when the class is defined, that is, when the file is imported. Even though the classes are never used, they are defined, so the class line, and all the lines immediately within it, are executed when the file is imported.
Notice that the one line you have inside a method (line 26) is marked as red, because it was never executed.
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) :
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.
I'm using RazorGenerator to unit test my Razor/MVC3 per David Ebbo's post here http://blog.davidebbo.com/2011/06/unit-test-your-mvc-views-using-razor.html and every time I attempt to use the AntiForgeryToken HtmlHelper (with no method arguments), it throws a NotImplementedException. What gives? As best I can tell, both my cshtml file and the view.generated.cs the correct method in System.Web.Mvc.dll, in the System.Web.Mvc namespace's HtmlHelper class. I've downloaded the latest source for the RazorGenerator project and don't see the word "forgery" contained within it anywhere, so I don't think I'm getting confused about exactly which HtmlHelper.AntiForgeryToken() method I'm hitting.
The code sample of my unit test follows:
[Test]
public void Index_RendersView()
{
var view = new Index();
// For test to succeed, this should not throw exception
view.RenderAsHtml();
}
Pretty basic. I'll spend some time digging under the hood to figure this one out and will follow up here if I figure this one out, but in the meantime I'm wondering if anyone else has encountered this and already worked out a solution.
I corresponded with David Ebbe, one of the (or, the) project owners on CodePlex, and he altered something within the RazorGenerator project source to fix this. Remarkably, he had it fixed within less than 1/2 hour of me asking the question on the CodePlex board.
I'm going to vote to have this question deleted since I don't think there's any value to keeping it around this site.
I am writing unit tests for a PHP class that maintains users in a database. I now want to test if creating a user works, but also if deleting a user works. I see multiple possibilities to do that:
I only write one method that creates a user and deletes it afterwards
I write two methods. The first one creates the user, saves it's ID. The second one deletes that user with the saved ID.
I write two methods. The first one only creates a user. The second method creates a user so that there is one that can afterwards be deleted.
I have read that every test method should be independent of the others, which means the third possibility is the way to go, but that also means every method has to set up its test data by itself (e.g. if you want to test if it's possible to add a user twice).
How would you do it? What is good unit testing style in this case?
Two different things = Two tests.
Test_DeleteUser() could be in a different test fixture as well because it has a different Setup() code of ensuring that a User already exists.
[SetUp]
public void SetUp()
{
CreateUser("Me");
Assert.IsTrue( User.Exists("Me"), "Setup failed!" );
}
[Test]
public void Test_DeleteUser()
{
DeleteUser("Me");
Assert.IsFalse( User.Exists("Me") );
}
This means that if Test_CreateUser() passes and Test_DeleteUser() doesn't - you know that there is a bug in the section of the code that is responsible for deleting users.
Update: Was just giving some thought to Charlie's comments on the dependency issue - by which i mean if Creation is broken, both tests fail even though Delete. The best I could do was to move a guard check so that Setup shows up in the Errors and Failures tab; to distinguish setup failures (In general cases, setup failures should be easy to spot by an entire test-fixture showing Red.)
How you do this codependent on how you utilize Mocks and stubs. I would go for the more granular approach so having 2 different tests.
Test A
CreateUser("testuser");
assertTrue(CheckUserInDatabase("testuser"))
Test B
LoadUserIntoDB("testuser2")
DeleteUser("testuser2")
assertFalse(CheckUserInDatabase("testuser2"))
TearDown
RemoveFromDB("testuser")
RemoveFromDB("testuser2")
CheckUserInDatabase(string user)
...//Access DAL and check item in DB
If you utilize mocks and stubs you don't need to access the DAL until you do your integration testing so won't need as much work done on the asserting and setting up the data
Usually, you should have two methods but reality still wins over text on paper in the following case:
You need a lot of expensive setup code to create the object to test. This is a code smell and should be fixed but sometimes, you really have no choice (think of some code that aggregates data from several places: You really need all those places). In this case, I write mega tests (where a test case can have thousands of lines of code spread over many methods). It creates the database, all tables, fills them with defined data, runs the code step by step, verifies each step.
This should be a rare case. If you need one, you must actively ignore the rule "Tests should be fast". This scenario is so complex that you want to check as many things as possible. I had a case where I would dump the contents of 7 database tables to files and compare them for each of the 15 SQL updates (which gave me 105 files to compare in a single test) plus about a million asserts that would run.
The goal here is to make the test fail in such a way that you notice the source of the problem right away. It's like pouring all the constraints into code and make them fail early so you know which line of app code to check. The main drawback is that these test cases are hell to maintain. Every change of the app code means that you'll have to update many of the 105 "expected data" files.