.Net 4.6.2 has a known breaking change. Path.GetDirectoryName no longer works with URI's. However for existing code which already uses this method, it breaks.
There is a workaround provided by Microsoft. We can add following config entry in runtime <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true"/>
UseLegacyPathHandling runtime switch supposed to allow existing code to work. It does work when I am running the application normally. However if same code block is executed in a Unit Test, it fails.
e.g.
class Program
{
static void Main(string[] args)
{
System.IO.Path.GetDirectoryName("file://localhost/etc/fstab");
}
}
[Microsoft.VisualStudio.TestTools.UnitTesting.TestClass]
public class TestClass1
{
[TestMethod]
public void TestUrl()
{
System.IO.Path.GetDirectoryName("file://localhost/etc/fstab");
}
}
In above code if I run the program directly then System.IO.Path.GetDirectoryName("file://localhost/etc/fstab"); statement runs fine. However if I run the unit test case then it fails. Why is it behaving like this?
After some debugging,I found "com.google.gwt.event.shared.UmbrellaException:One or
more exceptions caught, see full set in UmbrellaException#getCauses' when calling method: [nsIDOMEventListener::handleEvent]"(in web model) is caused by runtime null pointer.Question is why this kind of runtime null pointer exception didn't got thrown out under host model.Actually,blow code won't thrown out any exception and even got alert popup in my laptop(gwt 2.4+java 7 64bit+ubuntu 12.04 64bit+eclipse 3.7).Anybody knows how to enforce eclipse throw out exception whenever a runtime null on JavascriptObject pointer occurs.
public class GWTTest implements EntryPoint
{
public static class JsObj extends JavaScriptObject
{
protected JsObj()
{
}
public final native void setValue(String Value)/*-{
this.Value=Value;
alert(Value);
}-*/;
}
public void onModuleLoad()
{
JsObj jsObj = null;
jsObj.setValue("val");
}
}
The compiler performs a number of optimizations to transform GWT/Java into Javascript.
Types and methods are made final - this allows later steps to understand which methods need to be dispatched as normal, and which can be made static, just calling a single implementation.
Methods are made static, where possible, which allows methods to be inlined
Where possible and reasonable, methods are inlined
That said... When I compile your sample, the body of onModuleLoad() is optimized out to this:
null.nullMethod();
This is the GWT compiler's way of saying 'this will never work' - it notices that the value is always null, and so the method can't be invoked on it. But in Dev Mode, apparently the null object is left pointing at the window object in JavaScript. This is filed at http://code.google.com/p/google-web-toolkit/issues/detail?id=6625 in the GWT project.
If you need to make sure you don't act on a null, test for null before calling the method - it'll get optimized out if, in a test like yours, the value is always null. Runtime exceptions shouldn't be used for controlling code anyway, so you should never rely on a NullPointerException to do anything in your code.
I am trying to deploy a bigger GWT project to start working on it. After several problems I finally ran into the following, which I am not able to solve:
Here is a random piece of code:
service.getSuggestionOracle(this.suggestionString.getText(), new AsyncCallback<List<Entity>>() {
#Override
public void onSuccess(List<Entity> result) {
suggestionString.setStyleName("searchInput");
processSuggestionOracle(result);
}
#Override
public void onFailure(Throwable caught) {
suggestionString.setStyleName("searchInput");
GWT.log("Suggestion fails.");
}
});
Eclipse complains about the two functions onSuccess and onFailure that:
The method onSuccess(List<Entity>) of type new AsyncCallback<List<Entity>>(){} must override a superclass method
Indeed when I hover over the: new AsyncCallback<List<Entity>>() statement, it tells me that If an RPC is successful, then onSuccess(Object) is called, otherwise onFailure(Throwable) is called.
I conclude that there IS a superclasses with declarations for onSuccess and onFailure, but the compiler doesn't find it.
I use GWT-2.4.0 and the GWT library is added to the classpath.
The code above is just a random example, there are about 150 similar errors all over the
project. Additionally, there are several imports like com.xind.gwt.dom.client.DOM,
that can not be resolved.
Does anybody have an idea what I am missing here?
There are two possibilities that I could think of:
you haven't extended RemoteServiceServlet on the server implementation.
or
In this code,
public void onSuccess(List result) {
}
you have List as the returned object. Is this a list of objects of a user-defined class or java datatype? If the list is a user-defined type, then you must serialize the corresponding class by implementing java.io.serializable;
I posted this on the TypeMock forums, but am too impatient to wait for a response there. This is a very n00b question.
I'm trying to set up a fake IContainer. Here's what I have:
var container = Isolate.Fake.Instance<IContainer>();
var program = Isolate.Fake.Instance<IProgram>();
Isolate.WhenCalled(() => container.Resolve<IProgram>()).WillReturn(program);
(IProgram is an interface in my code).
When I try to run this code, I get an Autofac exception: "The requested service MyApp.IProgram has not been registered."
How could this exception be thrown though? I'm not actually calling container.Resolve(), right? I'm just setting it up to return a fake IProgram.
Unrelated background info: I'm trialing TypeMock because Autofac uses extension methods extensively and Moq won't mock them.
A couple of things that may help - first, you can mock Resolve() calls with Moq by setting up IComponentContext.Resolve(), which all of the extension methods delegate to.
Second, Autofac is designed so that you shouldn't have to use its interfaces from your components. See for examples:
http://nblumhardt.com/2010/01/the-relationship-zoo/
http://code.google.com/p/autofac/wiki/TypedNamedAndKeyedServices and
http://code.google.com/p/autofac/wiki/DelegateFactories
Where you need to use (and thus mock) IContainer or a similar interface, you can probably do the same thing using the Func, IIndex and/or Owned relationship types.
Hope this helps!
Nick
Unfortunately, there's currently a bug in Isolator, which prevents faking Autofac containers. We're working to resolve it as soon as possible.
In the mean time, is there a reason you're not using Autofac as intended, meaning have it return a fake instance, such as:
[TestFixture]
public class TestClass
{
private ContainerBuilder builder;
private IContainer container;
[SetUp]
public void SetUp()
{
builder = new ContainerBuilder();
}
[Test, Isolated]
public void Test1()
{
var fakeProgram = Isolate.Fake.Instance<IProgram>();
builder.RegisterInstance(fakeProgram).As<IProgram>();
container = builder.Build();
var program = container.Resolve<IProgram>();
Assert.AreEqual(fakeProgram, program);
}
}
We use TeamCity as our CI server, and I've just started seeing "TestFixtureSetUp Failed" in the test failure window.
Any idea how I go about debugging this problem? The tests run fine on my workstation (R# test runner in VS2008).
It is a bit of a flaw in the implementation of TestFixtureSetUp (and TestFixtureTearDown) that any exceptions are not well reported. I wrote the first implementation of them and I never got it to work the way it was supposed to. At the time the concepts in the NUnit code were tightly coupled to the idea that actions were directly related to a single test. So the reporting of everything was related to a test result. There wasn't really a space for reporting something that happened at the suite level without a huge re-write (it isn't a refactoring when you change a sheep into an escalator).
Because of that bit of history it's hard to find out what really happened in a TestFixtureSetUp. There isn't a good place to attach the error. The TestFixtureSetUp call is a side effect of running a test instead of being directly related to it.
#TrueWill has the right idea. Check the logs and then modify the test to add more logging if necessary. You might want to put at try/catch inside the TestFixtureSetup and log a lot in the catch block. I just thought I could add some background to it (in other words it's kind of my fault).
I'd check the Build Log first.
If it's not obvious from that, you could try including Console.WriteLines in the tests - I'm not positive, but I think those are written to the Build Log. Alternately you could log to a file (even using log4net if you wanted to get fancy).
If you have Visual Studio installed on the CI server, you could try running the build/tests from there. If it's a connectivity issue, that might resolve it.
I've seen path issues, though, where relative paths to files were no longer correct or absolute paths were used. These are harder to debug, and might require logging the paths and then checking if they exist on the build server.
I ran into this today when creating some integration tests that have long running setup that I don't want to duplicate. I ended up wrapping all the test fixture setup logic in a try/catch. I then add a SetUp method whose sole purpose is to see if a failure occurred during fixture setup and provide better logging.
Exception testFixtureSetupException = null;
[TestFixtureSetUp]
public void FixtureSetup()
{
try
{
// DoTestFixtureSetup
}
catch (Exception ex)
{
testFixtureSetupException = ex;
}
}
[SetUp]
// NUnit doesn't support very useful logging of failures from a TestFixtureSetUp method. We'll do the logging here.
public void CheckForTestFixturefailure()
{
if (testFixtureSetupException != null)
{
string msg = string.Format("There was a failure during test fixture setup, resulting in a {1} exception. You should check the state of the storage accounts in Azure before re-running the RenewStorageAccountE2ETests. {0}Exception Message: {3}{0}Stack Trace:{4}",
Environment.NewLine, testFixtureSetupException.GetType(), accountNamePrefix, testFixtureSetupException.Message, testFixtureSetupException.StackTrace);
Assert.Fail(msg);
}
}
I was getting the same error while running any test with SpecFlow using Visual NUnit. When I tried doing the same from the Unit Test Explorer(provided by Resharper), it gave a little more helpful message: Binding methods with more than 10 parameters are not supported. I realized I can't have a SpecFlow method with more than 10 params, had to remove the test.
I was able to see that I was not creating my test database correctly by doing a quick switch to VS Unit Testing. In my Case it was able to return a better response to the reason why it failed. I usually use NUnit.
"Unable to create instance of class X. Error: System.Data.SqlClient.SqlException: A file activation error occurred. The physical file name '\DbTest.mdf' may be incorrect. Diagnose and correct additional errors, and retry the operation.
CREATE DATABASE failed. Some file names listed could not be created. Check related errors..
"
Run the unit test in debug mode. You may find a runtime error in the the setup.
If you are using SpecFlow and C# in Visual Studio, look at the auto-generated <whatever>.feature.cs file after the test fails. On the public partial class <whatever>Feature line, you should see a symbol which when hovered over will show the reason that the NUnit fixture setup failed. In my case, it was that some of my BeforeFeature methods in my TestHooks class were not static. All BeforeTestRun, AfterTestRun, BeforeFeature, and AfterFeature methods need to be static.
I had this issue and it was caused by adding a private readonly Dictionary in the class, much the same way that you add a private const string.
I tried to make the Dictionary a constant but you can't do that at compile time. I solved this by putting my Dictionary in a method that returns it.
I was troubled by this today. I did the following to get the actual error.
(1) Write another test in a separate fixture which initializes an instance of the troubling test fixture, explicitly calls setup methods such as TestFixtureSetUp and SetUp if any, and then executes the target test method.
(2) Add exception handling code for the new code above, and log / output the actual exception to somewhere.
You can catch the exception and write it in the console on the TearDown
Something like:
[SetUpFixture]
public class BaseTest
{
private Exception caughtException = null;
[SetUp]
public void RunBeforeAnyTests()
{
try
{
throw new Exception("On purpose");
}
catch (Exception ex)
{
caughtException = ex;
}
}
[TearDown]
public void RunAfterAnyTests()
{
if (caughtException != null)
{
Console.WriteLine(string.Format("TestFixtureSetUp failed in {0} - {1}", this.GetType(), caughtException.Message));
}
}
}
And the result will be:
TestFixtureSetUp failed in IntegratedTests.Services.BaseTest - On purpose
I had this symptom caused by an error during field initialization. If you initialize your fields in the [SetUp] method, you should see a better error message.
[TestFixture]
internal class CommandParserTest
{
// obscure error message
private CommandParser parser = new CommandParser(...);
...
}
[TestFixture]
internal class CommandParserTest
{
private CommandParser parser;
[SetUp]
public void BeforeTest()
{
// better error message
parser = new CommandParser(...);
}
...
}