I am just jumping into testing of a GUI-heavy app written in C++(MFC) and C# (WinForms, WPF).
I have played with coded ui tests briefly, and I am happy with what I see. The trouble is that my program is non-trivial, so this does not work for me for 2 reasons:
VS 2010 Coded UI Test - Launch Referenced Application
There are 3 programs to launch in certain order, and I need to log in to one of them. Timing is important; I need to make sure that they have come up.
Start-up time is long, so I want to make sure that this set up is only done once per project.
When the project is done, I want to cleanly destroy this thing.
For each test I would want to make sure that the windows is active and is in the forefront at the beginning of each test.
What are some good approaches? If you find that this question is too vague, please let me know what it is missing.
There is code that gets generated for the coded UI tests. You can edit the coded UI test and add your own code to wait for things to occur before letting the next recorded step to take place. If you want to bring a certain application to the forefront, you can use Process.GetProcessesByName to get process information about your running application(s) and get its mainwindow handle to bring it to the front.
I you want to delay your test and wait some tasks (for example log-in or server response) you can check this article.
http://msdn.microsoft.com/en-us/library/gg316453.aspx
Related
I created a Winforms dashboard for my team using Powershell and I've put alot of features into the the thing (a tab that does webscraping, another tab that uses an API, another tab that sends emails, etc) and I just realized that I am unable to run different features simultaneously.
Some of the functions take awhile to actually run (like 1 minute or so) and while one feature is running, the entire winforms application is frozen until it finishes, before users are able to move onto another feature.
Is there a way around this? I know I can't be the only one who's ran into this issue. I want users to be able to run different dashboard functions simultaneously.
All of my code is currently in 1 .PS1 file which has over 1500 lines of code. I was thinking of maybe segmenting it off into different scripts and then having my dashboard call those other scripts once a function is invoked? Although I'm not so sure that would do what I'm looking to accomplish.
Any suggestions would be much appreciated.
This is more of a general theory question as I'm stuck on how to proceed since this is my first time developing an application...
I'm developing a reporting application in VS 2015 that requires two types of functionality. It needs to have a GUI so that users can interact with and create reports and those reports need to be scheduled via Windows Task Scheduler. I'm planning on using a Console Application for the scheduling portion. My question is, what would be the best way to implement this? As of right now I have two separate Projects in a single Solution. Is this the best route to take considering my needs or is there a better option that I'm not aware of? I've done some searching online but have not been able to find a valid solution. It's especially difficult since the scheduling portion needs to pull the application settings from the Windows Form Application.
Any help or guidance would be greatly appreciated. Thank you in advance!
The only reason you would need a console application would be if you actually needed a console interface. It doesn't sound like that's the case—the interface will be written in WinForms. Therefore, you don't actually need two separate applications. You can combine all the necessary functionality in a single executable.
The way to do this is by checking for command-line parameters that indicate whether the app should run interactively or headless. Probably, what you'll want to do is make the app run interactively when no command-line parameters are passed. This would be the normal case, the situation the user gets into when they double-click your app to launch it from Explorer.
When it comes time to schedule your app to run a task in the background (with Task Scheduler or anything else), you signal this by passing a special command-line parameter to your app. You can decide what this is, and you may need several of them if your app can do multiple things in the background. If configuration information/parameters need to (or can) be passed to the app to configure how it should perform the background task, you can pass these on the command line, too. Or, as you mention in the question, you could pull these settings from whatever was set/saved by the user the last time they ran the interactive version of the app.
The trick is just checking for these command-line parameters in your application's Main method. In the design I proposed, if there are no command-line parameters specified, then you just go ahead and create the main form like you normally would. If there are command-line parameters, then you need to parse them to see what action is being requested. Once you've parsed them and determined which background task should be run, you just run that background task—without ever creating/showing a form.
There are lots of different solutions for parsing command-line parameters. Using a library would probably be the easiest way, and also give you the most features. But if you just needed something really simple, like a /background mode, then you could easily write the code for this yourself, without taking a dependency on a library or needing to learn how to use it.
So you could do all of this with a single project in a single solution if you wanted to. Or, you could split different aspects of the functionality out into different projects that compile to libraries (e.g., DLLs), but still have only a single executable for simplicity.
My development system uses different clients for development and testing which I assume is a common practice. Unfortunately this introduces a rather annoying convenience issue when it comes to debugging. While breakpoints placed on the development system will stick to their code and move as lines are inserted or deleted, this is rather obviously not the case for breakpoints placed on the same code in another client.
Since the system has no knowledge of exactly how rows were changed between two versions, breakpoints placed in the testing client will remain at a particular line in the program. Any change to the code will therefore break the breakpoints. To resolve this I have to: open another program or screen then return to the program to refresh the code (where's the refresh button SAP?), find where the breakpoints have been moved to and remove them one-by-one (where's the batch remove breakpoints button SAP?) and then set new breakpoints at usually the exact same location.
This problem is becoming so frequent in my work that I sometimes spend more time moving breakpoints than I spend on the actual development. In some cases I just gave up and started coding in user breakpoints since those will at least remain in place. However, these come with their own drawbacks as they can't be removed in the debugger, making them useless when you are forced to stop at every breakpoint in a thousand-record loop.
My actual question is now whether there's a better approach or best practice when it comes to debugging in this scenario. I'm relatively new to ABAP programming so I hope that more experienced developers have alternatives or tricks that they use to speed this process up. Is there some better way to go about debugging and breaking code in a secondary client?
You could try creating a checkpoint group in transaction SAAB, and code the break-points to the checkpoint group.
Syntax
BREAK-POINT ID zyour_new_checkpoint_group.
This has the advantage that you can activate it for a set time, or a set of users etc. However, I'm not sure that if you get stuck in a 1000-line loop that you will be able to just deactivate it & skip over the break-point.
It may be worthwhile to check first if you can deactivate the checkpoint group on the fly while the program is running before using this in anger.
The practice of having a development client and test client makes sense for client dependent objects, e.g. customizing. It ensures a reasonably stable environment for development testing. But it makes no sense for programs and other development objects since they are client independent. However, it is still important that all your client dependent development objects (e.g. standard texts and SapScripts) originate from the development client so it is best to create all your objects there. But once you have done that and are on to testing and debugging there is no technical reason to not just change your program in the test client.
It might take some effort to convince the people responsible for development procedures of this practice since there always is a chance that objects get created in the wrong client which could lead to a mess when you want to release them. But with the scenario you describe in your question you should be able to plead your case.
For about a year a half, I've been working with SilkTest, which is a GUI automation tool, for both desktop and web applications. It simulates mouse and keyboard inputs, which eventually simulate end user behaviour. However, I find that it is a bit flaky; Button.Click() or DialogBox.Close() method calls that work just fine 9 times in a row seem to fail on a 10th call, only to go back working on the 11th. Normally I would just chalk this up to a quirk with SilkTest (or the application under Test, or the OS, or what have you) but then I see that there are similar issues with other GUI automation tools like Selenium:
Selenium Click() fails with Anchor Elements
Selenium Click() fails clicking button object
I know that for desktop apps, each GUI control/dialog has a tag element associated with it (at least in Windows-based GUIs) and that for web pages there is the domain object model hierarchy of page elements. My guess is that these tools sometimes run into issues navigating these hierarchies and finding unique elements and controls. But what is going on here? SilkTest is a relatively old, commercial software package while selenium is relatively new, open source and constantly evolving. The fact that they both can have similar problems raises a couple of flags with me.
Also, is this the case with other GUI test tools? Or have I just had a somewhat unusual experience?
There are 2 things here that you are talking about, first the concept of finding an object in the application under test that you want to automate. Your description of how SilkTest (and other tools) does this is quite accurate, i.e. as long as there is something that the automation software can use to identify the control then you are fine.
The second thing is why does the automation itself fails randomly, since the tool has not reported that it could not find the control then it must think that it sent the appropriate action to the application, e.g. a Click or a Type. This could be that the application is not ready to accept the action that you are sending it, this is similar to you attempting to click on something "before it was ready", in this case the application can decide to buffer the input or to discard the input.
So, how do you fix this? One way would be to use the capabilities of the tool to try to work out when the application is ready for input rather than sending it a stream of input blindly. SilkTest has capabilities that allow for you to do this (as does TestPartner). I cannot comment on Selenium as it is something I have not used.
A simple way of testing this would be to insert a pause for a couple of seconds before the offending action, then run this in a loop to see whether this solves the problem, if this is the case then it is your problem. If this does not fix the issue then there is something else going on that you need to contact the vendor of the testing tool.
Remember that applications are getting more and more complex, i.e. multi-threading, communications, any one of these could cause the automatic syncronisation to fail causing actions to fail.
Hope that helps.
I'm struggling with AutoIt regression tests. AutoIt was chosen because requirement is 100% blackbox GUI testing (no intervention to tested project). This solution has nevertheless got some issues, with which I need help.
Changing tabs in application - Because GUI class isn't SysTabControl32, but SWT_Window, example code from GUITab.au3 UDF doesn't work. Current solution is focusing on component and then navigating through tabs with arrow keys. This has a bad influence on test performance (and I don't even want to imagine a future possibility of some tab being disabled).
Timeouts - When tabs are changing, tests have to delay before they can proceed. The shorter the delay, the bigger the probability of test failure (app wasn't ready for test to continue). This leads to big delays before actions.
Instance numbers - Identifying instances of controls is a problem. When I wrote some test button OK it had instance number 9. When some buttons were added to the form I had to rewrite the test, because instance number of OK button changed because of this.
These three are most important.
Changing technology of testing would be hard because of big amount of already written tests. But I would like to write new test in a better way. Sikuli has problems getting text from screen and SWTBot has dependencies in tested projects.
Our tests run for 20 hours and when GUI layout changes I need to edit almost every test (instance number problem). Can anybody suggest a solution or workaround for ultra reliable blackbox testing?