I am using Ranorex to do automation tests against our application, which consists of several 3rd party controls, like the DevExpress GridControl. In most cases the grid rows are accessible. However, it can happen that the grid rows are not accessible (for about 1 minute), only if you play with Ranorex Spy for a some time.
Do you know where the problem could be?
That sounds strange. Does that mean that the grid can be recognized after one minute and that only happens with Ranorex Spy. What if you run the test?
You wrote that it happen sometimes, did you already find out when?
Is there a difference when using the external Spy and the Spy which is integrated in Ranorex Studio?
I know I'm very late to this question, but I've found that grid size can have a big impact on this. As far as I can tell, it's not that the rows and cells are "not accessible", it's that Ranorex is trying to load all of them before showing you info about them, and while this works fine on small grids, it apparently doesn't scale well. Try running your tests on smaller data sets.
Related
I am currently working with a Banking firm, we have a requirement to develop a fairly complex but Rich UI application. We are using EXTJS 4.2 and Spring MVC.
The first release of the app went into Production about a month back.
Now while modelling the new phase, we have come across a major hurdle. The application load up time is fairly high at this point of time. This is happening because the application has followed a single Page web 2.0 model and multiple JS files which when minified -> all-classes.js is 3 MB.
Now there is a lot of work to be done going ahead in order to build additional functionality.
Since all code is getting loaded at once during startup it would take a lot of time for this.
I figured out a design but I am not sure if that would help.. If we divide our application into multiple pages each have a different --> all-classes.js , will it help improve the performance ?
I need some advice on this.
You can refer to this links which I found : http://docs.sencha.com/extjs/4.2.0/#!/guide/command_app_multi
http://www.sencha.com/forum/showthread.php?130449-Large-Single-Page-Architecture-in-ExtJS-4.0/page2
Well, there are a number of answers to this, the best of which is "it depends".
Splitting into multiple pages is obviously going to produce some performance improvements. After all, you'll (presumably) have smaller files to initially load, fewer controllers to instantiate, etc.
The question is how much? I'm not sure I can answer that very well, without knowing more about the app and how it's structured.
I do know this, however. I have an app whose all-classes.js is around 2 MB. While there is obviously the initial hit loading it, subsequent visits use a cached version of it. And even the initial load of the 2MB file is pretty fast on most decent connections.
I took the time to set up some Unit Tests and set up the targets in XCode, etc., and they're pretty useful for a few classes. However:
I want to test small UI pieces for which I don't want to launch the entire application. There is no concept of pass/fail: I need to "see" the pieces, and I can make dummy instances of all the relevant classes to do this. My question is: how can I set this up in XCode?
I realize I could use another XCode project for each class (or groups of classes), but that seems a bit cumbersome. Another target for each?
I know that you're looking for an approach to testing UI components that doesn't require a fully functional application, but I've been impressed with what the new UI Automation instrument introduced in iOS 4.0 lets you do.
This instrument lets you use Javascript scripts to interactively test your application's interface, and it does so in a way that does not require checking exact pixel values or positions on a screen. It uses the built-in accessibility hooks present in the system for VoiceOver to identify and interact with components.
Using this instrument, I have been able to script tests that fully exercise my application as a user would interact with it, as well as ones that hammer on particular areas and look for subtle memory buildups.
The documentation on this part of Instruments is a little sparse, but I recently taught a class covering the subject for which the video is available on iTunes U for free (look for the Testing class in the Fall semester). My course notes (in VoodooPad format) cover this as well. I also highly recommend watching the WWDC 2010 video session 306 - "Automating User Interface Testing with Instruments".
Well, you cannot call showing a piece of some GUI a testing even if that GUI is a part of a large application. What you can do here is create a separate executable target and write a small tool that reuses GUI components from your application and shows them to you basing on input parameters. This will eliminate the need for many many different targets.
If you still insist on using unit tests, you can show your GUI for some period of time, for example, 10 seconds. So the test case will run until GUI is closed or timeout elapses and each test will take up to N seconds to execute.
This is a good question. I think you actually do not want to use unit tests for those 'visual confirmations'. Personally I usually write little test apps to do this kind of testing or development. I don't like separate targets in the same project so I usually just create a test project next to the original one and then reference those classes and resources using relative paths. Less clutter. And it is really nice to be able to test more complex user interface elements in their own little test environment.
I would take a two-level approach to UI "unit testing":
lthough Cocoa/CocoaTouch are still closer to the Model-View-Controller than the Model-View-ViewModel paradigm, you can gain much of the testability advantage by breaking your "View" into a "view model" and a "presenter" view (note that this is somewhat along the lines of the NSView/NSCell pair; Cocoa engineers had this one a long time ago). If the view is a simple presentation layer, than you can test behavior of the view by unit testing the "view model".
To test the drawing/rendering of your views, you will have to either do human testing or do rendering/pixel-based tests. Google's Toolbox for Mac has several tools for doing pixel-by-pixel comparison of rendered NSViews, CALayers, UIViews, etc. I've written a tool for the Core Plot project to make dealing with the test failures and merging the reference files back into your unit test bundle a little easier.
I am considering making use of GWT as the front-end to an existing web application.
I can't justify a complete rewrite to 100% GWT in one go. It is likely that I would migrate parts of the system to GWT gradually. However for consistency I would like to make use of the GWT TabPanel, MenuBar, etc as global interface elements from day one.
As an experiment to see how 'legacy' parts of the system could be incorporated, I have done the following.
The application's main page template now loads a small 'wrapper' GWT module on every page. This GWT module looks for a selection of DIVs in the dynamically generated host page. If the DIV is found, a suitable widget is slotted into place, i.e. menuBar, tabPanel.
A lot of the configuration for the included widgets can also be slotted into the host page as JSON structures. For instance, I have implemented an adapter that dynamically sets up a TabPanel in this way. I've also added some very simple widgets that load remote HTML, etc.
As a prototype, this all appears to work perfectly and loads quickly.
However, it seems that GWT apps are really designed to be run from a single host page, not hundreds of dynamically generated ones.
Can anyone highlight any issues that the above approach may run into, particularly as the GWT module increases in size? I would aim to keep the legacy wrapper module intentionally lean. Other functionality would be implemented in separate modules.
How have other people integrated GWT into their front end in a gradual fashion?
One of the ways GWT was designed to be used is exactly as you've used it. We have done that in many of our apps - where there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not. So I don't see that you'll have any issues at all going this way. We often use this approach even for new web applications, where we just want a few 'widgets' on the page, rather than coding the whole application in GWT.
It won't make a huge difference, but one thing I would suggest is not putting the GWT javascript code into your main template, but rather only put it on the pages that need it. It's true that if you're not running HTTPs it is cached basically forever, but it seems wrong to get people to load in the module if it's not actually needed on that page. This of course depends on how people use your site, if they are likely to download it anyway then it won't make any difference.
You're doing it right. Avoid avoid avoid the temptation to try to 'minimize' the GWT footprint by breaking it up into multiple separate apps.
The key to GWT performance is to have as few downloads as possible and to make sure they're cached. Loading a 250k bundle once is much better than two 200k bundles and because compression get's better with larger files you really start to reap benefits as things grow.
y-slow & firebug can be really helpful when it comes to convincing yourself of this.
One performance trick you might check out is available in the sample chapter here: http://www.infoq.com/articles/progwt
It shows a mini-architecture around loading GWT widgets into any number of slots and pre-populating data in JavaScript variables. This allows your GWT widgets to load and not require a second HTTP GET to get the data they use. In practice I found that this was a nice performance boost.
I asked this question a while back and basically the project almost consists of reproducing excel in the browser. We want people to input data in an excel-like way. The question i have is, what is the best control to use? Should i use a regular table, and then append columns to it, or should i use a datagrid and flip it XtoY? What approach would you take?
Thanks for any help.
Unless you have a TON of development time, don't try to do it yourself. Try a 3rd party control like Telerik or ComponentOne. None will probably have every feature you wish for, but you should be able to find one that is close enough.
Option 1: Check out the Silverlight option to develop your application. And it had a good Excel like DataGrid which is rendered at the Browser lever and you can have async calls to server at any point of time you want to persit a change.
Option 2: There are many datagrids available in WPF and you can get a high performance application using .NET3.5, and it is possible to host this as XBAP application.
Option 3: Typical ASP.NET with AJAX enabled Datagrid
I'd recommend ExtJS for an editable data grid with an AJAX data source. ExtJS is a bit bulky but very flexible.
Check out SpreadsheetGear. It's a drop in control that mimics (and works with) Excel for .Net. I've seen it used well for both display and back-end calculations.
The Farpoint Spread control emulates Excel grids pretty well, you can even code formulas behind it. It does cost money though
Maybe the new Datagrid that is in the wpf toolkit on codeplex has what you need. This datagrid can be templated and style the way you need it.
Our company is currently writing a GUI automation testing tool for compact framework applications. We have initially searched many tools but none of them was right for us.
By using the tool you can record test-cases and group them together to test-suites. For every test-suite there is generated an application, which launches the application-under-test and simulates user-input.
In general the tool works fine, but as we are using window handles for simulation user input, you can't do very many things. For example it is impossible for us to get the name of a control (we just get the caption).
Another problem using window handles is checking for a change. At the moment we simulate a click on a control and depending on the result we know if the application has gone to the next step.
Is there any other (simpler) way for doing such things (for example the message queue or anything else)?
Interesting problem! I've not done any low-level (think Win32) Windows programming in a while, but here's what I would do.
Use a named pipe and have your application listen to it. Using this named pipe as a communication medium, implement a real simple protocol whereby you can query the application for the name of a control given its HWND, or other things you find useful. Make sure the protocol is rich enough so that there is sufficient information exchanged between your application and the test framework. Make sure that the test framework does not yield too much "special behavior" from the app, because then you wouldn't really be testing the features, but rather your test framework.
There's probably way more elegant and cooler ways to implement this, but this is what I remember from the top of my head, using only simple Win32 API calls.
Another approach, which we have implemented for our product at work, is to record user events, such as mouse clicks and key events in an event script. This should be rich enough so that you can have the application play it back, artificially injecting those events into the message queue, and have it behave the same way it did when you first recorded the script. You basically simulate the user when you play back the script.
In addition to that, you can record any important state (user's document, preferences, GUI controls hierarchy, etc.), once when you record the script, and once when you play it back. This gives you two sets of data you can compare, to make sure for instance that everything stays the same. This solution gives you tests that not easy to modify (you have to re-record if your GUI changes), but that provide awesome regression testing.
(EDIT: This is also a terrific QA tool during beta testing, for instance: just have your users record their actions, and if there's a crash, you have a good chance of easily reproducing the problem by just playing back the script)
Good luck!
Carl
If the Automated GUI testing tool has knowledge about the framework the application is written in it could use that information to make better or more advanced scripts. TestComplete for example knows about Borland's VCL and WinForms. If you test applications build using Windows Presentation Foundation has advanced support for this build in.
use NUnitForms. I've used them with great success for single and multi threading apps and you don't have to worry about handles and stuff like that
Here are some posts about NUnitForms worth reading
NUnitForms and failed DragDrop registration - problem of MTA vs STA
Compiled application exe GUI testing with NUnitForms
I finally found a solution to communicate between the testing-application and the application-under-test: Managed Spy. It's basically a .NET application build on top of ManagedSpyLib.
ManagedSpyLib allows programmatic access to the Windows Forms controls of another process. For this it uses Window Hooks and memory-mapping files.
Thanks for all who helped me to get to this solution!
Managed Spy does not provide a solution for compact framework applications.
The company Jamo Solutions (www.jamosolutions.com) meets the requirements for automation testing on mobile devices, including .net compact framework applications.