I have a simple test method so far just to call the static method Main in Program.cs on a netcore mvc app.
My assert is never hit and the test just keeps running in the test explorer, even after 5 or 10min. Is it because the Program needs termination or is my implementation wrong for the test?
Advice appreciated
Thanks
Rob
[TestClass]
public class ProgramTests
{
[TestMethod]
public void ExecMain()
{
var args = new string[] { };
Program.Main(args);
// never hits test condition and test keeps running
Assert.IsTrue(true);
}
}
Your implementation is not wrong since you are following the AAA practice (Arrange, Act, Assert).
It seems, however, that you have not figured out what is to be tested. Are you expecting Program.Main to run forever? or should it terminate in some point? (something or someone should probably cause termination.)
If you can find out how to cause termination, you should do it in your test and then make the assertion (which obviously reflects your expectations from termination.)
Related
Probably not a good title, and this question might be stupid, but I really have no idea how to do this.
I've created a project that connects to a DB with EF Core . I've created my DbContext class and my Repository class that does the actual querying .
Then I created another class , maybe I created it wrong, but I made it similar to a controller of an MVC project . This is my class:
public class ExtractCustomersToBeMarked
{
private ICampaignRepository _repository;
private ILogger<ExtractCustomersToBeMarked> _logger;
public ExtractCustomersToBeMarked(ILogger<ExtractCustomersToBeMarked> logger, ICampaignRepository repository)
{
_repository = repository;
_logger = logger;
}
public async Task ExtractCustomers()
{
IEnumerable<CampaignKnownCustomers> result = _repository.getCustomersGUID();
... I want to debug this code
}
}
Now I want to debug my program . I tried calling the method from my Main program , but with no success as I don't know what to pass to the constructor (MVC does that on its own) . That's what I tried :
public static void Main(string[] args)
{
var p = new Program();
p.Run().Wait();
}
private async Task Run()
{
ExtractCustomersToBeMarked ectm = new ExtractCustomersToBeMarked(?,?);
await ExtractCustomersToBeMarked.ExtractCustomers();
}
I know it doesn't look good, this structure is simply for debugging . If theres another way I'm open to hear about it..
How can I hit the debugger on ExtractCustomers?
I guess you have implemented a CampaignRepository class. Provided that you want to use this implementation when debugging the ExtractCustomers() method, you should simply create an instance of it and pass to the method:
static void Main(string[] args)
{
ExtractCustomersToBeMarked ectm = new ExtractCustomersToBeMarked(null, new CampaignRepository());
ectm.ExtractCustomers().Wait();
}
The same goes for the logger. Create an instance of a class that implements the ILogger<ExtractCustomersToBeMarked> if you use the logger in the method that you want to debug. Don't forget to pass it to the constructor of the ExtractCustomersToBeMarked class when you create an instance of it.
You may want to implement an integration test instead of modifying the Main() method of the application itself though but that's another story.
Summary I'd suggest writing Unit Tests against the code you want to debug.
Detail When you have Unit Tests in place you can run each individual test under Debug, allowing you to step through the code exactly like you do when debugging the application; but with the benefit that you get to define the scope and context of the test, for example you can test isolated parts of your system independently of others.
Once a test is in place, it can shorten the time taken by the code+debug iteration cycle, making you more productive. It achieves that because the test fires you straight into the relevant code with the test scenario already set up, rather than the whole application having to start up, and you navigating through to the relevant parts each time to get into the scenario you want.
Another benefit of these tests (if they are written the right way) is that you can make them run as part of an automated build which is triggered whenever someone changes some code. This means that if anyone breaks that code, the test will fail, and the build will fail.
I was wondering if it was possible to have a start-up script before running any load tests? For example, perhaps to seed some data or clear anything down prior to the tests executing.
In my instance I have a mixed bag of designer and coded tests. Put it simply, I have:
Two coded tests
A designer created web test which points to these coded tests
A load test which runs the designer
I have tried adding a class and decorating with the attributes [TestInitialize()], [ClassInitialize()] but this code doesn't seem to get run.
Some basic code to show this in practice (see below). Is there a way of doing this whereby I can have something run only the once before test run?
[TestClass]
public class Setup : WebTest
{
[TestInitialize()]
public static void Hello()
{
// Run some code
}
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
{
return null;
}
}
Probably should also mention that on my coded tests I have added these attributes and they get ignored. I have come across a workaround which is to create a Plugin.
EDIT
Having done a little more browsing around I found this article on SO which shows how to implement a LoadTestPlugin.
Visual Studio provides a way of running a script before and also after a test run. They are intended for use in deploying data for a test and cleaning up after a test. The scripts are specified on the "Setup and cleanup" page in the ".testsettings" file.
A load test plugin can contain code to run before and after any test cases are executed, also at various stages during test execution. The interface is that events are raised at various points during the execution of a load test. User code can be called when these events occur. The LoadTestStarting event is raised before any test cases run. See here for more info.
If you are willing to use NUnit you have SetUp/TearDown for a per test scope and TestFixtureSetUp/TestFixtureTearDown to do something similar for a class (TestFixture)
Maybe a bit of a hack, but you can place your code inside the static constructor of your test class as it will automatically run exactly once before the first instance is created or any static members are referenced:
[TestClass]
public class Setup : WebTest
{
static Setup()
{
// prepare data for test
}
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
{
return null;
}
}
I have a test suite running in Automation. All of these tests are functional UI tests. It looks like below
[SetUp]
public void Setup()
{
CreatePolicy();
}
[Test]
public void Test1()
{
EditPolicyAndValidateResults();
}
[Test]
public void Test2()
{
EditPolicyAndValidateResults();
}
[TearDown]
public void TearDown()
{
DeletePolicy();
}
Now, the problem is DeletePolicy() is failing sometimes (randomly for one or two of the tests) and because of which the corresponding tests are failing.
To circumvent the failure if have added a try catch block to DeletePolicy() and it looks like the following:
[TearDown]
public void TearDown()
{
try
{
DeletePolicy();
}
catch(Exception ex)
{
// Do nothing
}
}
Since testing DeletePolicy() function is not the intent of my test cases, the approach looks fine to me. Is this correct or I am missing something here?
The general pattern of Unit Testing is: Arrange, Act then Assert: AAA.
Setup is just a designated method to Arrange the test in a better way (for example by re-setting any previously mocked/stubbed objects to save time and to avoid code duplication). It is by no means mandatory and is just a way to help test coder to code better.
TearDown again and in the same way is a helper and it is even farther to the generic concept of AAA than Setup. It is because in AAA nothing regarding destructing or cleaning up is mentioned.
So, feel free to ignore any failure in TearDown unless it is somehow important. Maybe there is something hidden from your eyes and you haven't taken into account yet. It may be important to make another unit test on failure point, but it totally depends on your case.
GOAL:
I want to use the TestContext.TestName property to extract the name of the test being ran so that my [TestCleanup] function can log the outcome to our bespoke results repository, automatically when every test completes.
PROBLEM:
Even in my basic 'sanity check' test project that contains 5 tests that are similar to the structure below:
[TestMethod]
public void TestMethodX()
{
Console.WriteLine(String.Format("In Test '{0}'",_ctx.TestName));
Assert.IsTrue(true);
}
With a Class 'initializer' like below which sets _ctx for me:
[ClassInitialize]
public static void ClassInit(TestContext Context)
{
_ctx = Context;
Console.WriteLine("In ClassInit()");
}
[[NOTE: the Console.WriteLines are purely there for me to hover the mouse over and inspect value/properties, etc.]]
The _ctx.TestName NEVER changes from the name of the first test in the run of tests, i.e. If I was to run all five tests ('TestMethod1', 'TestMethod2', 'TestMethod3', etc.) they all log 'TestMethod1' as their testname in my results repository.
Running the tests individually it works fine, but that is of no use to me as I need to be able to run 10's/100's/1000's of tests against my application and have the testContext handle the testname or me.
I have tried this several times now and searched the internet loads and haven't anyone else with this problem, so i'm either: unique with this problem, have poor 'Google-Fu' skills, or am doing something REAL stupid. Hopefully this makes sense and someone has the answer.
Thanks in advance,
Andy
This is happening because the [ClassInitialize] is executed only once for the whole test run and you initialize the _ctx in there. Use the [TestInitialize] instead, which is executed before each test method and override the TestContext Class :
[TestClass]
public class TestClass
{
public TestContext TestContext { get; set; }
[TestInitialize]
public void Initialize()
{
// Runs once before each test method and logs the method's name
Console.WriteLine(TestContext.TestName);
}
[TestMethod]
public void TestMethod1()
{
// Logs the method name inside the method
Console.WriteLine(String.Format("In Test '{0}'", TestContext.TestName));
}
// ... Your rest test methods here
}
MSTest.exe outputs can be configured to output a .trx (xml)file with the complete results of you test, names , passed or failed and output from any of those test, there is also a tool to convert the TRX file to HTML http://trxtohtml.codeplex.com/
Hope this helps
When I write a test in Visual Studio, I check that it works by saving, building and then running the test it in Nunit (right click on the test then run).
The test works yay...
so I Move on...
Now I have written another test and it works as I have saved and tested it like above. But, they dont work when they are run together.
Here are my two tests that work when run as individuals but fail when run together:
using System;
using NUnit.Framework;
using OpenQA.Selenium.Support.UI;
using OpenQA.Selenium;
namespace Fixtures.Users.Page1
{
[TestFixture]
public class AdminNavigateToPage1 : SeleniumTestBase
{
[Test]
public void AdminNavigateToPage1()
{
NavigateTo<LogonPage>().LogonAsCustomerAdministrator();
NavigateTo<Page1>();
var headerelement = Driver.FindElement(By.ClassName("header"));
Assert.That(headerelement.Text, Is.EqualTo("Page Title"));
Assert.That(Driver.Url, Is.EqualTo("http://localhost/Page Title"));
}
[Test]
public void AdminNavigateToPage1ViaMenu()
{
NavigateTo<LogonPage>().LogonAsCustomerAdministrator();
Driver.FindElement(By.Id("menuitem1")).Click();
Driver.FindElement(By.Id("submenuitem4")).Click();
var headerelement = Driver.FindElement(By.ClassName("header"));
Assert.That(headerelement.Text, Is.EqualTo("Page Title"));
Assert.That(Driver.Url, Is.EqualTo("http://localhost/Page Title"));
}
}
}
When the second test fails because they have been run together
Nunit presents this:
Sse.Bec.Web.Tests.Fixtures.ManageSitesAndUsers.ChangeOfPremises.AdminNavigateToChangeOfPremises.AdminNavigateToPageChangeOfPremisesViaMenu:
OpenQA.Selenium.NoSuchElementException : The element could not be found
And this line is highlighted:
var headerelement = Driver.FindElement(By.ClassName("header"));
Does anyone know why my code fails when run together, but passes when run alone?
Any answer would be greatly appreciated!
Such a situation normally occurs when the unit tests are using shared resources/data in some way.
It can also happen if your system under test has static fields/properties which are being leveraged to compute the output on which you are asserting.
It can happen if the system under test is being shared (static) dependencies.
Two things you can try
put the break point between the following two lines. And see which page are you in when the second line is hit
Introduce a slight delay between these two lines via Thread.Sleep
Driver.FindElement(By.Id("submenuitem4")).Click();
var headerelement = Driver.FindElement(By.ClassName("header"));
If none of the answers above worked for you, i solved this issue by adding Thread.Sleep(1) before the assertion in the failing test...
Looks like tests synchronization is missed somewhere... Please note that my tests were not order dependant, that i haven't any static member nor external dependency.
look into the TestFixtureSetup, Setup, TestFixtureTearDown and TearDown.
These attributes allow you to setup the testenvironment once, instead of once per test.
Without knowing how Selenium works, my bet is on Driver which seems to be a static class so the 2 tests are sharing state. One example of shared state is Driver.Url. Because the tests are run in parallel, there is a race condition to set the state of this object.
That said, I do not have a solution for you :)
Are you sure that after running one of the tests the method
NavigateTo<LogonPage>().LogonAsCustomerAdministrator();
is taking you back to where you should be? It'd seem that the failure is due to improper navigation handler (supposing that the header element is present and found in both tests).
I think you need to ensure, that you can log on for the second test, this might fail, because you are logged on already?
-> putting the logon in a set up method or (because it seems you are using the same user for both tests) even up to the fixture setup
-> the logoff (if needed) might be put in the tear down method
[SetUp]
public void LaunchTest()
{
NavigateTo<LogonPage>().LogonAsCustomerAdministrator();
}
[TearDown]
public void StopTest()
{
// logoff
}
[Test]
public void Test1()
{...}
[Test]
public void Test2()
{...}
If there are delays in the DOM instead of a thread.sleep I recommend to use webdriver.wait in combination with conditions. The sleep might work in 80% and in others not. The wait polls until a timeout is reached which is more reliable and also readable. Here an example how I usually approach this:
var webDriverWait = new WebDriverWait(webDriver, ..);
webDriverWait.Until(d => d.FindElement(By.CssSelector(".."))
.Displayed))
I realize this is an extremely old question but I just ran into it today and none of the answers addressed my particular case.
Using Selenium with NUnit for front end automation tests.
For my case I was using in my startup [OneTimeSetUp] and [OneTimeTearDown] trying to be more efficient.
This however has the problem of using shared resources, in my case the driver itself and the helper I use to validate/get elements.
Maybe a strange edge case - but took me a few hours to figure it out.