I'm trying to make some refactorings in order to change namespace of some classes, create projects, etc.. using EnvDTE CodeModel.
I have tried various methods I found on the web, but nothing seems to work.
I'm using .Net 5.
For example, in this page are using directly DTE.Solution but when I try it on my solution, Intellisense gives me an error.
var solution = DTE.Solution;
Error: An object reference is required for the non-static field, method or property '_DTE.Solution'.
Another example I have found here is the following:
var dteInstance = serviceProvider.GetService(typeof(EnvDTE.DTE));
If I do that, the serviceProvider returns null to me. So I can't work with DTE.
I just need some help in order to get an instance of DTE, and later I would test all methods and properties that it gives me. But, how can I get the instance of DTE? How can I work with that?
I'm using an MVC web application to test it.
I appreciate so much your help.
I want to create a scheduler inheriting cScheduler. Can someone please tell me which are the functions to be written which must override the functions of cscheduler? Currently, I have written the constructor, destructor, startRun, endRun, guessNextEvent, takeNextEvent, putBackEvent. I have also mentioned the class in the initialization file and able to successfully build my project but when I run the simulation I get the error: Class TraCIConnection" not found -- perhaps it's code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels with Define_Module()/Define_Channel().
The mentioned error has absolutely nothing to do with the custom scheduler you are trying to implement. Omnet complains because you are using the TraCIConnection simple module in the simulation while its C++ code is not linked into the simulation. You may need to add the C++ code to the project or link with an external model that provides that.
I have a unit test that behaves differently depending on parameters passed. Does VS 2010 MS Testing framework have a facility to call the same test with different parameters.
I am looking for something like this:
[TestRun(False)]
[TestRun(True)]
[TestMethod]
public void FooTest(bool a)
{
RunTest(a);
}
I have no idea why Micosoft's decided not to include this feature in their unit testing framework, whenever I search for it I find reference to the DataSource attribute that enable loading data from external resource (XML file, data base etc.)
If you do not want to use and external data source then you have two choices:
Add RowTest support using MSTest extensability framework - explained here
I wrote in my blog how to use PostSharp to create the external data source from the test attributes.
If you're already using VS2010 I suggest you go with the first option - there is even a full working code at Microsoft's code gallery.
The following page tells how to achieve the same with MSTest data-driven testing capabilities: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.dataaccessmethod.aspx
Test driven development on wikipedia says first develop a test that will fail because the feature does not exist. Then build the code to pass the test. What does this test look like?
How do you figure out what test will best represent the feature you want to create?
Can someone give an example?
Like if I make a logout button feature to a web application then would the test be hitting the page looking for the button? or what?
I heard test driven is nice for regression testing, I just don't know how to start integrating it with my work.
Well obviously there are areas that are more suited for TDD than others, and running frontend development is one of the areas that I find difficult to do TDD on. But you can.
You can use WATIN or WebAii to do that kind of test. You could then:
Write a test that checks if a button exists on the page ... fail it, then implement it, and pass
Write a test that clicks the button, and checks for something to change on the frontend, fail it, implement feature and pass the test.
But normally you would test the logic behind the actions that you do. You would test the logout functionality on your authenticationservice, that is called by your eventhandler in webforms, or the controller actions in MVC.
What does this test look like?
A test has 3 parts.
it sets up a context
it performs an action
it makes an assertion that the action did what it was supposed to do
How do you figure out what test will best represent the feature you want to create?
Tests are not based on features (unless you are talking about a high level framework like cucumber), they are based on "units" of code. Typically a unit is a function, and you will write multiple tests to assert all possible behaviors of that function are working correctly.
Can someone give an example?
It really varies based on the framework you use. Personally, my favorite is shoulda, which is an extension to the ruby Test::Unit framework
Here is a shoulda example from the readme. In the case of a BDD framework like this, contextual setup happens in its own block
class UserTest < Test::Unit::TestCase
context "A User instance" do
setup do
#user = User.find(:first)
end
should "return its full name" do
assert_equal 'John Doe', #user.full_name
end
context "with a profile" do
setup do
#user.profile = Profile.find(:first)
end
should "return true when sent #has_profile?" do
assert #user.has_profile?
end
end
end
end
Like if I make a logout button feature to a web application then would the test be hitting the page looking for the button? or what?
There are 3 main types of tests.
First you have unit tests (which is what people usually assume you are talking about when you talk about TDD testing). A unit test tests a single unit of work and nothing else. This means that if your method usually hits a database, you make sure that it doesn't actually hit that database for the duration of the test (using a technique called "mocking").
Next, you have integration tests. An integration test usually involves interaction with the infrastructure, and are more "full stack" testing. So from your top level API, if you have an insert method, you would go through the full insert, and then test the resulting data in the database. Because there is more setup in these sorts of tests, they shouldn't really be run from developer machines (it is better to automate these on your build server)
Finally, you have UI testing. This is the most unreliable, and requires a UI scripting framework like Selenium or Waitr to automate clicking around your UI. Don't go crazy with this sort of testing, because these tests are notoriously fragile (a small change can break them), and they wont catch whole classes of issues anyways (like styling).
the unit test would be calling the logout function and verifying that the expected results occurred (user login record ended, for example)
clicking the logout button would be more like an acceptance test - which is also a good thing to do, and (in my opinion) well within the scope of TDD, but it tests TWO features: the button, and the resulting action
It depends on what platform you are using as to how your tests would appear. TDD is much harder in ASP.NET WebForms than ASP.NET MVC because it's very difficult to mock up the HTTP environment in WebForms to get the expected state of Session, Application, ViewState etc. as opposed to ASP.NET MVC.
A typical test is built around Arrange Act Assert.
// Arrange
... setup needed elements for this atomic test
// Act
... set values and/or call methods
// Assert
... test a single expected outcome
It's very difficult to give deeper examples unless you let us know the platform you plan to code with. Please give us more information.
Say I want to make a function that will add one to a number (really simple example).
First off, write a test that says f(10) == 11, then do one that says f(10) != 10. Then write a function that passes those tests. If you realise the function needs more capabilities, add more tests.
The test would be making sure that when the logout function was executed, the user was successfully logged out. Generally a unit testing framework such as NUnit or MSTest (for .Net stuff) would be used.
Web applications are notoriously hard to unit test because of all the contextual information generally required for the execution of server code on a web server. However, a typical example would mock up that information and call the logout logic, and then verify that the correct result was returned. A loose example is an MVC type test using NUnit and Moq:
[Test]
public void LogoutActionShouldLogTheUserOut()
{
var mockController = new Mock<HomeController>() { CallBase = true };
var result = mockController.Object.Logout() as ViewResult;
Assert.That(result.ViewName == "LogoutSuccess",
"Logout function did not return logout view!");
}
This is a loose example because really it's just testing that the "LogoutSuccess" view was returned, and not that any logout logic was executed. In a real test I would mock an HttpContext and ensure the session was cleared or whatever, but I just copied this ;)
Unit tests would not be testing that a UI element was properly wired up to an event handler. If you wanted to ensure that the whole application was working from top to bottom, this would be called integration testing, and you would use something besides unit tests for this. Tools such as Selenium are commonly used for web integration tests, whereas macro recording programs are often used for desktop applications.
I am testing my routes in an mvc app. I have the following code:
using System.Web.Routing;
using MvcContrib.TestHelper;
using NUnit.Framework;
using web;
using web.Controllers;
namespace tests.web.Routes
{
[TestFixture]
public class routeTests
{
[Test]
public void Route_POSURL_MapsToPOSIndex()
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
"~/POS".ShouldMapTo<POSController>(x => x.Index());
}
[Test]
public void Route_POSGetItem_MapsToPOSGetItem()
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
"~/POS/GetItem/12345".ShouldMapTo<POSController>(x => x.GetItem());
}
}
}
However, the 2nd test fails stating:
System.ArgumentException: A route named 'Default' is already in the route collection. Route names must be unique.
If I run either test individually they run fine. Obviously NUnit is sharing my Routing table across tests. Why?
I know I can put my RegisterRoutes call in a TestFixtureSetup method but this doesn't answer the issue and I'd like to know what I am missing.
Am I just missing something? How come I can't find this question anywhere else on the net?
Thanks!
Matt
I don't think it's NUnit sharing the routes - I do believe that is how ASP.NET MVC works. FWIW, when testing my routes I usually put RegisterRoutes in [TestFixtureSetup]. You'd probably be okay to just do the same thing.
I found this great article from Martin Fowler which explains what is going on:
http://martinfowler.com/bliki/JunitNewInstance.html
Kudos to the xUnit Test Patterns book, as it's the one that led me to the article.
I don't know if it's because I used to be a Java guy or if I just made some assumptions. JUnit creates a new TestCase object for every single method when you run tests. That means that even global variables are reset for every single test method and are not shared.
This is not the case with NUnit. NUnit creates only one TestCase object, thus any global variables are shared. Tom, you're right in the fact that MVC creates the global variable for my routes, however, NUnit does not dump this and create a new one for each test like most other xUnit frameworks do.
I have placed the register routes code in the TestFixtureSetup method, and it works of course. I'm glad that I understand what's going on now.