I have written a test with WatiN and when a step through the code with F10, the test succeeds, but when I execute the 'Run Test' command from the context menu, the test fails.
Here's my test:
[TestMethod]
[STAThread]
public void Should_show_captcha_after_three_invalid_login_attempts_with_invalid_username()
{
// Given
int numberOfLoginAttempts = 3;
// When
for (int loginAttempt = 1; loginAttempt <= numberOfLoginAttempts; loginAttempt++)
{
EnterUsername(LoginSettings.ValidUserName);
EnterPassword(loginAttempt.ToString());
ClickLoginButton();
// Check we are still on the loginpage
Assert.IsTrue(_browser.Title.Contains("Inloggen"));
}
bool isCaptchaVisible = _browser.Page<LoginPage>().Captcha.Exists;
// Then
Assert.IsTrue(isCaptchaVisible);
// Make sure to clear the login attempts for next test cases
RemoveLoginAttempts();
}
FYI: In the DB we keep track of the loginAttempts based on the username. When the number of loginattempts is > 2, the captcha is shown. The problem I encounter is that the counter in the DB stays 1. When I manually step through the test, the counter is increased.
How is this possible?
Well you are right it's got to be timing. However part of the problem is this is not a unit test, and the other is there's a great deal of asynchronous stuff going on that you are assuming will have completed before you execute another line of test code which has been written on the assumption that it has.
For instance the count in your loop for login attempts is definitely not the one in the db. All things being equal it should match up, but..
So to me you should have a test of the login function.
That logins up the colunt in the db if unsucessful, and reset that count if it succeeds.
Then an other test to see that when login attempts in the db has gone over the limit, login response detects that and shows the the correct response.
If you want to join all this up for an end to end / whitebox test. Then an automation test of some description should be used.
I suspect that windows, the browser, your webserver or even your dbms didn't get time to finish processing the first login attempt, before you'd queued up another two, and then done the test. Whereas in debug mode inbetwen you stepping through, they have plenty of time.
Related
My current solution to ask the CNC (via ThincAPI) whether or not the program has Completed is not working. It doesn't care if I change programs, once it is successful it will always report true even after changing the loaded program.
What I would like is a variable that I can reset right before firing cycle start so I can check and see if the program truly ran. Ideally I would reset this CycleComplete method that is already being used.
I think what I'm going to end up doing is writing to a macro (common) variable and setting a value, then having the GCode change that value at the very end of the GCode program. Then I will read that value to verify it changed.
Okuma.CMDATAPI.DataAPI.CProgram myCProgram;
myCProgram = new Okuma.CMDATAPI.DataAPI.CProgram();
...
case "cycle":
string cycle = myCProgram.CycleComplete().ToString();
Console.WriteLine(" Response: " + cycle);
return cycle;
You might have to check machine in Auto Mode, and running status by using
CMachine class with method
GetNCStatus ()
GetOperationMode()
In the case of schedule program, part program is loaded really fast by NC. As a result, you might always see RUNNING status.
Using CV is also a good way to ensure that program have been set/reset.
I suspect you must be using an SDF Scheduled Program and the next program is being called before your application has a chance to catch that the previous .MIN program has completed.
The CycleComplete() method will reset when a new program is selected.
If it is returning true and the program in question didn't complete, that is because the subsequent .MIN program completed.
I would suggest putting a Dwell in between the PSelect calls in the SDF to give your app time to catch that the previous .MIN has completed or not.
Just wondering if anyone might be able to point me in the right direction here.
user = await App.MobileService.LoginAsync(provider)
this is the line of code in question. The problem is; this works fine on 2/3 test machines (All Windows 10), the dialog is displayed and the program operates as expected. on the third machine however, the dialog does not display. I have wrapped the function in a try catch block and I am catching all exceptions that I then route to a MessageDialog to display on the screen. the messages are never shown, as though the try succeeded, but the function exits on that line exactly and throws no exceptions. I am using MobileServiceAuthenticationProvider.MicrosoftAccount as my provider.
Code redacted to highlight the error, the full code returns a boolean value for success/failure. All traces past the failing line do not appear, so the function is definitely exiting at the specified line.
try
{
//This line fails on a single machine out of three
user = await App.MobileService.LoginAsync(provider)
}
catch(Exception e)
{
//when it fails, this does not trigger, and no traces after this point
//appear until outside the function
MessageDialog msg = new MessageDialog(e.ToString());
await msg.ShowAsync();
}
and just to make things really weird...message dialogs prior to this point in the code work just fine...
I suspect that the security of the machine in question is blocking the login (windows defender), but I really have no idea where to look for this, or even how to test the problem further. Any ideas as to what would prevent this single machine from displaying the Microsoft login window, or ideas on further debugging would be appreciated.
You are not awaiting the response from the Async reply. This means that you will have an ordering and concurrency issue - sometimes it will work, and sometimes it won't and it's all in the timing.
You need:
var user = await client.LoginAsync(provider);
i want to truncate table using console application with parameter hour.
for example, i want to run query truncate at 12.00 AM using time in system.
this is my code in console application using c#.
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string getHour = DateTime.Now.ToString("h:mm:ss tt");
if (getHour == "12:00:00 AM")
{
Console.WriteLine("Do action to run query truncate");
//in this line i will execute query truncate.
}
// Keep the console window open in debug mode.
Console.WriteLine("Press any key to exit.");
Console.ReadKey();
}
}
}
And this is not working. please give me solution or sample code to fix my problem.
thanks...
I would suggest few things on your code:
Don't use string comparison, but uses DateTime directly (take a look on TimeOfDay.TotalSeconds). This way, it makes the comparison a lot easier
Use repeated calls instead of just one call (unless you can really be sure that you run your program exactly at 12). This way you make your program work for you more.
To make it more robust, provide some ways to give tolerance to your system. This is how good automation should be.
Example:
namespace ConsoleApplication1 {
class Program {
static void Main(string[] args) {
while (true) { //read 2. assuming this is to be run forever in this example, but gives also some way to break the loop whenever necessary in your app
if (DateTime.Now.TimeOfDay.TotalSeconds <= 1) { //read 1. and 3. this way, you give tolerance of 1 second. Your action will be run on 12:00:00 - 12:00:01
Console.WriteLine("Do action to run query truncate");
// //in this line i will execute query truncate.
break; //break after saving once, for instance, and run again when the time close... This is to prevent possible multiple executions...
}
System.Threading.Thread.Sleep(500); //read 2. and 3. check every 500 millisecond, at least to give chance to check the time twice per second
}
// Keep the console window open in debug mode.
Console.WriteLine("Press any key to exit.");
Console.ReadKey();
}
}
}
When you run your program, it looks on the clock quickly, and if it is not exactly midnight immediately exits. (To be more precise it prints some message and waits until keypress). I believe you wish to wait until midnight. If the exact timing is not that important (I mean some seconds early or late is acceptable), the simplest solution is:
static void Main(string[] args)
{
Thread.Sleep(DateTime.Today.AddDays(1) - DateTime.Now);
Console.WriteLine("It's about midnight, I go to sleep");
}
I feel like the issue is with the flow of execution of your code.
You're calling the code once and then it stops. It checks once NOW and get the current time. If the time is 12:00:00 AM, you can pass into the if statement, but you'll need to literally run this at 12:00:00 System time on the dot, which is nearly impossible.
You should consider a Windows Service or using Windows Task Manager: C# Console Application - Keep it running.
As mentioned in the other answers you shouldn't be using your app to schedule the task. It looks like you are doing a database maintenance task so the first thing I would look at is...
1) See if your database can schedule tasks. SQL Server Agent for example can schedule stored procedures (or adhoc SQL) to be run at set times and would accomplish your task if you are using that for your database. More info here.
If your database can't do this or you want to do other things other than truncate the table then...
2) try using Windows Task Scheduler
This can launch an application at set times, is easy to setup and then your application can just do the job it's mean to do (e.g. truncate the table) and not worry about the scheduling.
I am fairly new to the testing environment but I am stuck with a problem.
i have created a test case (a few tests combined in an ordered test) and when I run them on my own pc they always pass (tried it many times to be sure) but when I run the test on our server the test fails at random times.
examples - he doesn't right click a list to get the context menu
- he seems to forget to click on a button so he cant access the next window. etc
if i run the test again he may go over the previous fail but fails on something else.
so far. out of +- 30 times i have run he test i had 5 success runs. and this should be a base test so there should be no bug or known problem.
i have the feeling that the server needs more time to complete the test. so i did research and already added many playbacksettings and a Playback_PlaybackError.
test case made in Visual studio 2013 part with recording part written code. build in visual studio and server tested with microsoft test manager 2013, win8 envir
is there anything i do wrong? or is there something wrong with the server configuration?
Thanks in advance.
so far I tried some of these (and repeat in every testmethod)
public CodedUITest1()
{
Playback.PlaybackSettings.MatchExactHierarchy = true;
Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.Control;
Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.TopLevelWindow;
Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.None;
Playback.PlaybackSettings.SearchTimeout = 2000;
Playback.PlaybackSettings.ShouldSearchFailFast = true;
Playback.PlaybackSettings.ThinkTimeMultiplier = 2;
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;
Playback.PlaybackSettings.WaitForReadyTimeout = 2000;
Playback.PlaybackError -= Playback_PlaybackError;
Playback.PlaybackError += Playback_PlaybackError;
}
/// <summary> PlaybackError event handler. </summary>
private static void Playback_PlaybackError(object sender, PlaybackErrorEventArgs e)
{
// Wait a second
System.Threading.Thread.Sleep(1000);
// Retry the failed test operation
e.Result = PlaybackErrorOptions.Retry;
}
Try to use
yourcontrol.WaitForControlReady()
function as well before performing any action on control. This function will stop the thread till your control becomes ready for accepting any action.
Seems the problem was server based. I added a global delaybetweenactions and the test seems to run very smooth. Problem fixed
I had the similar problem with a set of 20 odd Coded UI Tests in my project, which used to randomly fail on the server, but always ran fine locally. We looked out for a number of troubleshooting techniques to overcome this mysterious 'random' factor. The biggest problem while analyzing these test failures is that the error stack trace might indicate the line of code which might be completely unrelated to the actual cause of failure.
We figured out that we can enable HTML logging in our Coded UI tests. This is very easy and can either be enabled for individual tests or for all the tests in the project. Just add the below code to your app.config file
Once you have the tracing enabled, the tests will display step by step details of how Coded UI tried to execute the tests - with screenshots of your application. This is very beneficial in troubleshooting the actual cause of test failures.
Im using the enum Microsoft.TeamFoundation.Build.Client.BuildStatus for each and it works great for the statuses contained in it.
But is there a blatantly obvious way of determining if a build is queued, but not yet in progress? I know the build explorer in visual studio can see this, im having problems getting that data programmatically.
Do i have to check something on the teamproject instead of the IBuildDetail itself? Any tips appreciated.
Unfortunately it doesn't appear that IBuildDetailSpec queries ever return queued builds. However, you can use the IQueuedBuildSpec interface to query for queued builds.
For example:
public IEnumerable<IQueuedBuild> getQueuedBuilds(TfsTeamProjectCollection tfsCollection, string teamProject)
{
// Get instance of build server service from TFS
IBuildServer buildServer = tfsCollection.GetService<IBuildServer>();
// Set up query
IQueuedBuildSpec spec = buildServer.CreateBuildQueueSpec(teamProject);
spec.Status = QueueStatus.Queued;
// Execute query
IQueuedBuildQueryResult result = buildServer.QueryQueuedBuilds(spec);
// Array of queued builds will be in the result.QueuedBuilds property
return result.QueuedBuilds;
}
You should be able to see the build status as BuildStatus.NotStarted once the build actually reaches the queue. There is a time before it reaches the queue that it really doesn't have a status, though.
If you're submitting your build programmatically, you can do:
bool success = queue.WaitForBuildStart(pollingIntervalInMilliseconds, timeOutInMilliseconds);
As long as the agent is listening, this should actually return very quickly. If you have a slow network, this could potentially take a couple seconds for handshaking.
Once it passes the WaitForBuildStart, the status is set to BuildStatus.NotStarted until it moves to InProgress and the rest of the way down the line.
#Greg Case
First thank you for the code , you gave me the solution that I was searching for. Second , I want to suggest using the same code snippet of yours to receive notifications from TFS for specific Queued build. I already used it to get notified that the build I queued is completed and it even returns exception details for failure case . To do that you need to connect() to the queued build returned from code and then register event , I wanted to add it as a comment but couldn't for long text
IQueuedBuild CurrentBuild = result.QueuedBuilds.First();
CurrentBuild.Connect();
CurrentBuild.PollingCompleted += CurrentBuild_PollingCompleted;