I use setId a lot for automated UI tests within my Vaadin application. For performance reasons, I would like to remove this ID's in production mode. Is there any good way to do so?
You can check if you are currently running in Vaadin Production Mode like this
VaadinService.getCurrent().getDeploymentConfiguration().isProductionMode();
So if you are setting your components id with setId() method, you can easily set it only when not in production mode, for example:
boolean isProductionMode = VaadinService.getCurrent().getDeploymentConfiguration().isProductionMode();
if(!isProductionMode) {
foo.setID(FOO_ID);
}
But I would consider whether to use this approach at all. To how many components do you assign id for web tests? If the number is not extremely high, the performance hit will be negligible, while your code will be cluttered too much with production mode checks. In many cases code readability and simplicity is more important than a minor performance hit.
Alternatively, you can rewrite many of your component selectors (assuming you are using Vaadin testbench?) using xpath queries which do not depend on component Ids but on some already present information instead - like "location" attribute when using custom layouts, css class, position in parent container etc.
Related
Here is my problem with my dropdowns:
As an automation tester, I have some issues using Selenium's Select(); method 'bout dropdown fields. If I have to run a test in multiple cycles and select different option from the dropdown every next cycle, I just used Select(); method and it worked great.
Now the problem is that in the HTML code I do not even see the option of the dropdown. The field is changed to dynamic, it is not static anymore.
How can I work around this feature or is it just a bad programming practice?
I think it's not bad practice to have dynamic options in a dropdown menu.
To write an end-to-end test for this it depends how dynamic these options are. If they change from release to release (e.g. the available product categories in the system), you should probably encode them in your test. In that way the test will have to be updated if the options are updated, which makes sense (the test will fail if it doesn't find the options it expects).
If the options change by external factors (e.g. the current top 10 trending topics on Twitter) then you cannot encode them in your test. You should then probably try to pick one by index (e.g. the first one) and parameterize the test to handle any value that might be there. Alternatively you could stub the 'TrendingValuesFromTwitterService' (staying with my example) to deliver a fixed set of values for your testing purposes.
Normally static data with Select, Dropdown or combobox is a best practice. Unfortunately, sometimes we need dynamic data with Selects. The best way is to use Fluent Waits for Select contains your option. Also, Thread.sleep() is another solution but it is not preferable. However, it is exact solution. Try to implement fluent or implicit waits for your select options.
For example, ElementToBeVisible or ElementToBeExists etc.
Checkout Selenium Docs
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.
Here is the context of my question. It is typical that one organizes configuration values into different files. In my case, my criteria is easy editing and portability from one server to another. The package is for Internet payments and it is designed so that a single installation of the package can be used for different applications. Also, we expect that an application can have different stages (development, testing, staging and production) on different servers. I use different files for each of the following three categories: the config values that depend only on the application, those that depend only on the server and those that depend on both. In this way, I can easily move the configuration values that depend only on the application from one server to another, say from development to production. They are edited often. So, it is worth it. Similarly, I can edit the values that are specific to the server in a single file without having to maintain redundant copies for the different applications. The term "configuration value" includes anything that must be defined differently in different applications or servers, even functions. If the definition of a function depends on the application or on the server, then it is a part of the configuration process. The term "configuration value" appeared natural to me, even it includes functions.
Now, here is the question. I wanted the functions to be PHPUnit testable. I use PHP, but perhaps the question makes sense in other languages as well. I decided to store the configuration values as properties and methods in classes and used class hierarchy to organize the different categories. The base class is PaymentConfigServer (depend only on the server). The application dependent values are in PaymentConfigApp extends PaymentConfigServer and those that depend on both are in PaymentConfig extends PaymentConfigApp. The class PaymentConfigApp contains configuration values that depend either on the application or on the server, but the file itself contains values that depend on the application only. Similarly, PaymentConfig contains all conf values, but the file itself contains values that depend on both only. Can this use of class hierarchy lead to issues? I am not looking for discussions about the best approach. I just want to know, if you met a similar situation, what issues I should keep in mind, what conflicts could arise, etc?
Typically, subclasses are used to add or modify functionality rather than remove functionality. Thus, the single-inheritance approach you suggested suffers from a conceptual problem that is likely to result in confusion for anyone who has to maintain the application if/when you get hit by a bus: the base class provides support for server-specific configuration, but then you (pretend to) remove that functionality in the PaymentConfigApp subclass, and (pretend to) re-add the functionality in its PaymentConfig subclass.
I am not familiar with the PHP language, but if it supports multiple inheritance, then I think it would be more logical to have two base classes: PaymentConfigServer and PaymentConfigApp, and then have PaymentConfig inherit from both of those base classes.
Another approach might be to have just a single class in which the constructor takes an enum parameter (or a pair of boolean parameters) that is used to specify whether the class should deal with just server-specific configuration, just application-specific configuration, or both types of configuration.
By the way, the approach you are suggesting for maintaining configuration data is not one that I have used. If you are interested in reading about an alternative approach, then you can read an answer I gave to another question on StackOverflow.
Is there a system for annotating HTML for the purpose of identifying elements/attributes critical to web user interface test automation (by Selenium, HTMLUnit, Watir, Sahi, etc.)? The system might be a standard or library. The annotations might for example be implemented as HTML data attributes which reference simply an attribute name, an XPath expression, or CSS selector that needs to exist and remain consistent for test automation purposes. If identified attributes/elements change, test automation may break, so developers should not change them without coordinating with those responsible for automation. So the annotations are at the very least a visual cue to developers.
But beyond that, perhaps an "enforcer" part of the system (continuous integration plugin, CLI, or perhaps JavaScript library on the same page) would enforce the annotations to some degree, failing quickly and clearly if certain conditions are not satisfied. Perhaps the identified attribute/XPath/selector must exist and reference the same element that defines the annotation. The enforcer can also gather all the annotations and perhaps report the full list of them on each page of a web application, for diff notification purposes.
I may have some details not well worked out, but hopefully the gist of what I'm looking for makes sense. A free license would be handy but not absolutely necessary.
Does something like this exist?
A helpful answer might also be:
There's a better way to address your underlying need (with explanation).
We tried implementing this and it's not worth it; here's why.
Motivation: Web user interface tests can be sensitive to changes to HTML elements and attributes. The tests often run in an integration testing job or phase which may be significantly later than the build or unit tests. It would be nice to catch some of the potential mismatches between UI elements and test expectations earlier, in the build or unit test phase, and also to provide a test automation engineer more information to indicate what may be a bug in a test vs. a bug in the product under test.
As you say:
The annotations might for example be implemented as HTML data attributes
This is the way people are going with HTML5 as it enables us to pass control over to our QA automation teams and lets development teams ignore their concerns (changing an ID on an element would affect their testing).
So, an HTML element might look like (a relatively contrived example):
<div id="button" data-test-attribute="submit"></div>
Most selectors used by these libraries use CSS-oriented selections, making selecting the above eay. There are a number of articles that have begun to address this.
A really brief one I like states:
ID’s and also css class names have another purpose than for the usage
in UI automated tests. Css classes are primarily used to style
elements and they also can get uglified on the production page. ID’s
have also another purpose and can also sometimes just change or they
are not get implemented because they interfere with other functions on
the page.
It seems another part of your question is concerned about enforcement. This would be relatively simple to integrate into your build process with a hand-spun thing using something like Node.js and webpack (might increase your build time, considerably - but certainly possible).
I was told in a previous question that there can be issues when using db4o server without persistent classes. On the Versant web site, they just say that native queries won't be available.
So what are the issues possible in this particular configuration, except less features ?
Some features do not work:
All query methods except SODA queries do not work.
Some type of objects my create issues like enums etc.
The main concern is just the 'stability' and 'matureness' of this feature. db4o hasn't been design to work without the classes available. The test-suite and feature design is centered around scenarios with classes available.
Or from the internal implementation standpoint: The 'generic'-reflection layer is very brittle. That's the component which is required for this feature.
Well if up for taking a risk and only use SODA as query engine you can try it. However if you rather do not run into bugs / limitations than avoid it.