I’m curious to know how feasible it is to get away from the dependency onto the application’s internal structure when you create an automated test case. Or you may need to rewrite the test case when a developer modifies a part of the code for a bug fix, etc.
We could write several automated test cases based on the applications internal object structure, but lets assume that the object hierarchy changes after 6 months or so, how do we approach these kind of issues?
I can't speak for other testing tools but at least in QTP's case the testing tool introduces a level of abstraction over the application so that non-functional changes in the application often (but not always) have no effect on the way the testing tool identifies the object.
For example in QTP all web elements are considered to be direct children of the document so that changes in the DOM (such as additional tables) don't change the object's description.
In TestComplete, there are a couple of ways to make sure that the changed app structure does not break you tests.
You can set up the Aliases tree of the Name Mapping feature. In this case, if the app structure is changed, you need to modify the Aliases tree appropriately and your test will stay working without requirement to modify them.
You can use the Extended Find feature of the Name Mapping in order to ignore parts of the the actual object tree and search for a needed objects on deeper levels.
This is what I was forced to do after losing all my work twice due to changes on the DOM structure:
Every single time I need to work with an object, I use the Find function with the ID of the object, searching for the object on the Page object. This way, whenever the DOM gets updated, my tests still run smoothly.
The only thing that will break my tests is if the object's ID get changed, but that's not very probable to happen.
Here you can find some examples of the helper functions I use.
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
I'm writing some functional tests for an API in Symfony that depend on having data in the database. It seems the generally accepted method for doing this is to use Fixtures and load the fixtures before testing.
It seems pretty daunting and impractical to create a robust library of Fixture classes that are suitable for all my tests. I am using the LiipFunctionalTestBundle so I only load the Fixtures I need, but it only makes things slightly easier.
For instance, for some tests I may need 1 user to exist in the database, and other tests I may need 3. Beyond that, I may need each of those users to have slightly different properties, but it all depends on the test.
I'd really like to just create the data I need for each test on-demand as I need it. I don't want to pollute the database with any data I don't need which may be a side effect of using Fixtures.
My solution is to use the container to get access to Doctrine and set up my objects in each test before running assertions.
Is this a terrible decision for any reason which I cannot foresee? This seems like a pretty big problem and is making writing tests a pain.
Another possibility it to try and use this port of Factory Girl for PHP, but it doesn't seem to have a large following, even though Factory Girl is used so widely in the Ruby community to solve this same problem.
The biggest reason to fixture test data in a single place (rather than in each test as needed) is that it allows you to isolate test failures from BC-breaking schema changes to only tests that are affected by the changes directly.
A simple example:
Suppose you have a User class, in which you have a required field name, for which you provide getName() and setName(). You write your functional tests without fixtures (each test creating Users as needed) and all is well.
Sometime down the road, you decide you actually need firstname and lastname fields instead of just name. Naturally you change the schema and replace getName/setName with new get and set methods for these, and go ahead and run your tests. Test fail all over the place (anything that sets up a User), since even tests that don't use the name field have called setName() during the setup, and now they need to be changed.
Compare to using a fixture, where the User classes needed for testing are all created in one fixture. After making your breaking change, you update the fixture (in one place / class) to setup the Users properly, and run your tests again. Now the only failures you get should be directly related to the change (ie tests that use getName() for something, and every other test that doesn't care about the name field proceeds as normal.
For this reason it's highly preferred to use fixtures for complicated functional tests where possible, but if your particular schema / testing needs make it really inconvenient you can set entities up manually in tests, but I'd do my best to avoid doing so except where you really need to.
Lets try this explanation again...
I'm new to polymer (and getting back into web dev after a relatively long absence), and I'm wondering what the recommended approach might be to more closely manage object state while employing 2 way databinding. I am currently consuming rest API (json) objects. My question is if polymer keeps a copy of the original object before initiating updates to the bound object's properties/attributes...so one might be able to easily undo the changes? While allowing 2 way databinding to work its magic is often desired, there are cases where I'd like to prevent / delay changes to the object / DOM until the user approves the changes (say via the paper-dialog component for instance). I suppose one could make a temporary copy of the object and bind fields to that version, and then only persist the changes back to the source object upon user approval. In any case, I'd be interested to hear thoughts and see an example or two of recommended approaches (especially if I am off-track with my ideas!)
I suppose one could make a temporary copy of the object and bind
fields to that version, and then only persist the changes back to the
source object upon user approval
This.
Consider that view-models are essentially different from pure data-models (sometimes called business-data). Frequently, the differences are irrelevant and one can use them interchangeably. However, be aware of scenarios where the view-model is distinct (uncommitted user edits are a good example).
The notion of a field editor that requires approval from the user is purely UI/View oriented. Whatever data is managed in that modality is purely in the domain of the view, and fetches/commits to the business-data should be discrete.
I am facing a common issue that most of us face while writing UI automation tests:
Strong coupling of automation tests with the AUT. If an enhancement changes UI of a module, you have to go and spend a lot of time changing:
1. Either the code (logic) to test the module.
2. Or just the locator of an element.
If the change in UI is minimum, it's ok to manually replace the locators in the test. But it is not possible to do this if the change is very large considering deadlines and time constraints.
I am trying to figure out a way to implement a tool / utility that will save my time from changing locators of any element in the web-app that I have stored in my locator map.
For example:
I have a locator for a search result list in my locator-map as:
searchResultsLocator=span[id="searchResults"] > ul > li[class="ui-menu-item"] > a
If a dev changes this by replacing the span with a div as a part of some patch, then I want this to get automatically get updated in my locator-map.
Has anybody worked on this problem? Can someone suggest something?
I am not sure if the problem is fixed or not, if not fixed you can try this..
I face the same issue is well but no more.
Create a file where you keep all the element references (if no ID is present you can use XPath) and then use a variable which takes value from this file instead of hardcoding it.
Do not create a single file for entire application, make sure you have related elements in a single file (say element of single page).
So when the UI changes you will have only one place to edit instead of entire test code.
You can use multiple/backup locators for each element. See my question here: Pros/cons for using multiple locators per element in Selenium?
This doesn't automatically update your locators for you, but I was afraid attempting to do so might update them incorrectly. And then you might end up with a kind of false positives - tests which pass because they auto-updated to new locators, but locators for the wrong elements!
However, pre-defining multiple locators allows your test to continue running smoothly when one locator fails, but you can generate reporting/notification about the failure, and then still have time to do your manual updating of locators, as long as at least one of those backups continues working.
Is there a list somewhere that lays out all of the types of changes that can be made to an existing workflow service that would prevent existing instances of the original workflow from being re-loaded? For example, I recently made a small change to a custom activity (changed a condition in an "if" statement) and all existing workflow instances still load as normal. Now, in the past, I had removed a property on an object that the workflow uses, and when I tried to re-load a persisted workflow instance, it blew up on me.
Does such a list exist? Thanks!
As far as I am aware there isn't a list like that. You really should consider all changes as breaking. If you test thoroughly you will find a few exceptions but these will be mostly changing a single VB expression.
There is no such a list.
As far as I am concerned, you can change VB expressions always editing the .xamlx in a text editor. I say that, because in my case, sometimes the graphical editor (VS2010) changed the ids of the activities without introducing new activities (be carefull with this).
You can also change the whole internal code (not the inputs/outputs parameters) in code activities (.xaml). Because of that, it would be a good idea to put all the "high changeable" logic into code activities in order to be able to modify this logic avoiding problems with existing WF instances.