In class they taught us to add a test fixture to the same namespace as the project we're testing. For example:
namespace Project
{
class Decrypt : Cipher
{
public string Execute()
{
//Code here
}
}
[TestFixture]
{
[Test]
public void test1()
{
//Code here
}
}
}
I noticed in the c# menu on my uni computer, there was a 'Test' section (I couldn't get it to run there either, I don't know how). On this old 32b computer there isn't. I've installed NUnit-2.6.2.msi but when I try to run it, it says "Unable to find a version of runtime to run this application"
So I think I have two problems:
installing Nunit (I already have referenced the .dlls from my project separately)
using Nunit (even on a computer with it installed properly)
Normally you'd put your code in separate projects, but reference the project you're testing in the test project
//project: Xarian.Security
//file: Decrypt.cs
namespace Xarian.Security
{
class Decrypt : Cipher
{
public string Execute()
{
//Code here
}
}
}
.
//project: Xarian.Security.Test
//file: DecryptTest.cs
using System;
using NUnit.Framework;
//as we're already in the Xarian.Security namespace, no need
//to reference it in code. However the DLL needs to be referenced
//(Solution Explorer, Xarian.Security.Test, References, right click,
//Add Reference, Projects, Xarian.Security)
namespace Xarian.Security
{
[TestFixture]
class DecryptTest
{
[Test]
public void test()
{
//Code here
Cipher cipher = new Decrypt("&^%&^&*&*()%%&**&&^%$^&$%^*^%&*(");
string result = cipher.Execute();
Assert.AreEqual(string, "I'm Decrypted Successfully");
}
}
}
Right click on the test project's references, go to the Projects tab and select the main project. Once referenced you'll be able to use the classes (etc) from your main project in your test code.
Related
I have two projects in Visual Studio, the core project which is a Windows Service Executable, and the Unit Test Project.
The core project has two original files broken out like this
File1.cs:
using static Proj.ConfigHelper;
namespace Proj
{
class MyClass
{
(lots of code)
}
}
File2.cs looks something like this.
namespace Proj
{
static class ConfigHelper
{
public static NameValueCollection AppSettings { get { return ConfigurationManager.AppSettings; } }
public static NameValueCollection CustomSection { get { return ConfigurationManager.GetSection("CustomSection") as NameValueCollection; } }
}
}
Both of those classes are internal and made visible to the unit test project via InternalsVisibleToAttribute.
Inside of the UnitTest project which is a discrete project within the same solution (and so it has its own app.config), calling ConfigHelper.AppSettings results in a 0-item collection, and calling ConfigHelper.CustomSection results in null. If I attempt to unit test a method within File1.cs that depends on those settings, they run as default values as if they were not configured at all. I don't quite understand why this is happening. Can anyone help me understand what I did wrong? It seems as though the ConfigHelper is not loading the App.Config for its own project.
The app.config for the Windows Service Project is set to "always copy" and the app.config for the unit test project is set to "never copy"
The test will use its own config so you need to mirror it. There are work runarounds: Can a unit test project load the target application's app.config file?
I have an NUnit test project dedicated for unit testing which has a Target Framework of .Net Core 2.1. This test project has references of two other Projects one of which is a Windows Form based application and the other is a Class Library based application for database interactions. Both of these projects has a target framework of .Net Framework 4.6.1
I am writing a test for testing a method of the Class Library based application to test the output of the method. But it's showing the following error,
'System.IO.FileNotFoundException : Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.'
I have tried the following fixes and none of them worked.
Removing the project references and adding them again
Changing build platform target from AnyCPU to X86 and x64
Adding dependant assemblies tag inside a .config file. (Interesting things is .NET Core 2.1 doesn't provide with a .config file)
This is the test class (Test_DataClasses.cs),
using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
using System.Data.SQLite;
using SharedDataClasses;
using MantechAutomationControl;
using System.IO;
using System.Reflection;
namespace MAC_Testing
{
[TestFixture]
class Test_DataClasses
{
#region Tests
[Test]
public void t_m_initializeDatabase()
{
//Assign
string v_dbLocation = Path.Combine("M:\\For_Jabed\\MAC\\MAC\\MantechAutomationControl\\bin\\Debug\\", "DB.sqlite");
//Act
DataClasses_v2.m_initializeDatabase();
//Assert
Assert.That(new FileInfo(v_dbLocation), Does.Exist);
}
#endregion
}
}
And this is the method the above test is trying to validate,
public static class DataClasses_v2
{
#region Variables
#endregion
#region Methods
public static void m_initializeDatabase()
{
string v_executableLocation = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string v_dbLocation = Path.Combine(v_executableLocation, "DB.sqlite");
if (!File.Exists(v_dbLocation))
{
DialogResult o_createDBFileDialogBox = MessageBox.Show("Could not find the database in the expected location:\n" + v_dbLocation + "\n\nWould you like to create a new blank database file?", "Warning", MessageBoxButtons.YesNo);
if (o_createDBFileDialogBox == DialogResult.Yes)
{
SQLiteConnection.CreateFile(v_dbLocation);
using (SQLiteConnection o_dbConnection = new SQLiteConnection(#"DataSource=" + v_dbLocation + ";Version=3;"))
{
o_dbConnection.Open();
}
}
else
return;
}
}
I don't really understand whats going on here. Although point to be noted I actually was working towards to use Nunit Form dll to work with Forms (DialogBox) as the method to be tested had a DialogBox to work with.
In the test project there is another class and the tests written inside those class works fine for the Same target 'Class Library' based project to validate a different function.
Hopefully someone will be able to explain whats going on here.
MyProject has an internal class and method as such.
namespace MyProject
{
internal class InboundMailAlertParser
{
internal InboundMailAlert ParseMessageBody(string body)
{
...
}
}
}
I'm using InternalsVisibleTo in my MyProject AssemblyInfo.cs to expose internal classes/methods to a unit test assembly.
[assembly: InternalsVisibleTo("MyProject.Tests")]
My Test looks like this
namespace MyProject.Tests
{
[TestClass]
public class InboundMailAlertParserTests
{
[TestMethod]
public void ParsesBody()
{
InboundMailAlertParser parser = new InboundMailAlertParser();
parser.ParseMessageBody(messageBody.ToString());
}
}
}
My test passes fine when run in Visual Studio, but nCrunch is failing to build the unit test project due to not being able to see the internal InboundMailAlertParser of the MyProject assembly under test. Is there another nCrunch assembly I have to indicate should have internal visiblity to allow nCrunch to be able to build the test assembly?
Turns out I had ignored a component (project) in the nCrunch config. Once I enabled that, the project could build correctly and I got my lovely green dots.
I have the following code:
[TestFixture]
public class LexicalTests
{
[Test]
public void LexicalTest1()
{
TestContext.CurrentContext.TestDirectory;
}
}
CurrentContext throws an exception while attempting to get TestDirectory or WorkingDirectory property.
How can I solve this problem?
P.S.: On my home PC tests work perfectly (without strange exceptions).
It seems that some applications that offer the functionality to run NUnit unit tests have a problem with the TestContext class.
The test in class below should pass:
using NUnit.Framework;
namespace UnitTests
{
[TestFixture]
public class UnitTests
{
[Test]
public void CurrentContextTest()
{
Assert.IsNotNull(TestContext.CurrentContext);
Assert.IsNotNull(TestContext.CurrentContext.TestDirectory);
Assert.IsNotNull(TestContext.CurrentContext.WorkDirectory);
}
}
}
If the test doesn't pass then, as Dmitry wrote in his comment above, change the NUnit version in the ReSharper menu. From within Visual Studio, go to ReSharper -> Options -> Tools -> NUnit. Click the Specified NUnit installation radio button and ensure that a folder with nunit.core.dll, nunit.core.interfaces.dll and nunit.util.dll is specified. An error will be displayed if the listed files cannot be found.
Once the NUnit version has been changed, re-run the test and it should pass.
I have created a simple class library project in visual studio 2008 that has one class as shown below. I am trying to get this class to register for COM interop so that I can use in via unmanaged scripts like vbscript or jscript.
In my project build properties I have checked the box that says "Register for COM Interop".
In the Assembly Settings I have checked "Make this assembly COM Visible" and I have confirmed that the [assembly: ComVisible(true)] attribute is present in the assembly.cs file.
Every time I build this project I get an error that reads "projectname.dll does not contain any types that can be registered for COM Interop. Also, I have not been able to successfully create an instance of class 1 using a vbscript. Does anyone know that this is not registering properly?
My vbscript fails to create activex object at this line... Set F = CreateObject("64BitCLTest.Class1").
Finally, how do I get VS to register this in the 64bit area of the registry instead of the 32 bit area so that 64bit processes can use it?
-- The Test Class--
namespace _64BitCLTest
{
[Guid("BBAA06EF-CA4C-4fe2-97CD-9B1D85ADA656")]
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
[ProgId("64BitCLTest.Class1")]
public class Class1
{
Class1()
{
// do nothing
}
public string Method1()
{
return "This is a return string from method 1";
}
public int Property1
{
get {return 777;}
}
}
}
you need to mark the constructor public:
-- The Test Class--
namespace _64BitCLTest
{
[Guid("BBAA06EF-CA4C-4fe2-97CD-9B1D85ADA656")]
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
[ProgId("64BitCLTest.Class1")]
public class Class1
{
public Class1()
{
// do nothing
}
public string Method1()
{
return "This is a return string from method 1";
}
public int Property1
{
get {return 777;}
}
}
}
There are two parts to this answer. The first, problem as consultutah said was that I did not have the constructor marked as public.
The second answer is that there is a bug (I believe) in VS2008 that causes assemblies to never be registered in the 64-bit section of the registry, even if the setup project is configured for a target platform of x64.
I installed VS2010, rebuilt the exact same project and ran the Install. The assembly registered perfectly and I was able to successfully access it through COM using a 64bit process. I still have not found a solution for this in VS2008.