The list of all of the expressions of Step Definitions (methods with #Given #When or #Then annotations) effectively defines the ubiquitous language that is available to be used to write Steps within Scenarios.
I have found myself loosing track of existing Step Definitions, and I have created different variants of existing Step Definitions with slightly different expressions. I have had to go back and refactor a number of times to eliminate duplicates. If only I had known about the original Step Definition in the first place ...
Is there an automated way of getting a list of all Step Definition expressions, preferably separated by the class they are in?
The expressions from annotations are what I specifically need, but bonus if it also works using Java 8 lambda means of defining Step Definitions.
Related
In AnyLogic
You may vary only the parameters of the top-level agent.
(https://anylogic.help/anylogic/experiments/optimization.html#:~:text=Optimization%20experiment&text=If%20you%20need%20to%20run,the%20optimization%20capability%20of%20AnyLogic.)
(https://anylogic.help/anylogic/experiments/parameter-variation.html)
The top-level agent can not have more than 255 parameters.
The number of method parameters is limited to 255 (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.11)
The question here is not why 255 parameters are required for an optimization problem or if simulation-based optimization is the best way to handle a problem with more than 255 parameters (Decision Variables). The question is about ways to overcome this limitation.
I thought
The best option would be to follow Java best practices and have a Java
class (which has almost no limitations) (Maximum number of parameters in a Agent-Type)
However,
AnyLogic provides Agents, that are basically predefined classes
with several built-in functionalities, (https://noorjax.com/2018/11/12/an-example-on-the-use-of-classes-in-anylogic/)
Therefore, it seems that using Java Class would not help. I'm I missing a Java trick here? would it be possible in any way to perform an optimization experiment in AnyLogic with more than 255 parameters?
Sorry if this question is not under the scope of SOF. I'm still trying to distinguish between what can be asked and what not.
There are several ways to avoid the limit:
Structure your parameters in 'raw' Java classes so, for example, your Main agent may have 3 parameters of type CoreParameters, ClimateVariables and EconomicVariables. (Just look at any Java tutorials for how to define simple classes which are effectively just data structures.) But now your experiments have to create appropriate instances of those classes as parameter values (and this makes things like a Parameter Variation experiment harder to define; you'd typically use a Custom Experiment instead since then you have full control of how you setup the parameters for each run). For optimisation, you'd also have to use a Custom Experiment to define an optimisation where, for example, you might have 500 optimisation variables but your code to setup the model from them sets up your 3 model parameter class instances with those 500 values. The Custom Experiment help page has examples of this.
Use external data (e.g., Excel loaded into the AnyLogic DB) to provide some/all of the 'parameters' for your model. The issue here is that AnyLogic's multi-run experiments (including optimisation-based ones) expect to be varying top-level agent parameters. But often
A load of 'parameters' will stay fixed so those can be supplied from this external data.
'Parameters' may be varied in related sets, so this can boil down to a single parameter which provides, say, the filename to load the relevant external data from (and you vary that across a pre-prepared set). But this requires writing some specific Java to allow you to import external data from a dynamically-defined filename into the AnyLogic DB, or the equivalent but reading directly from the Excel file. (But this is simple boilerplate code you can copy and reuse once you've 'learnt' it.)
P.S. I'd reiterate though that any optimisation involving 255+ parameters is probably pointless, with little likelihood of finding a near-optimum (and if you have a model with that many parameters --- given that you might genuinely want to vary all of them independently --- you have a model design problem).
P.P.S. Your two quoted bits of text don't contradict each other. You can write raw Java classes in AnyLogic or use, say, an Agent which just contains a set of parameters as a 'data structure class'. Agents (together with everything else) are Java classes, but that's not relevant to your question.
In our Behave-based BDD tests we see a need to add some metadata to the scenarios (for the purpose of test reports). The data is in the form of key/value pairs with a handful of keys and values are typically numbers. The structure will be parsed by our custom test report generator during and/or after the test run.
Is there a canonical way to do this in Gherkin? We considered adding them to the text of the scenario itself, e.g.
Scenario: Some scenario (somekey=42)
When ...
Behave also supports tags
#sometag(42)
Scenario: Some scenario
When ...
but since tags have side effects (test selection), this seems messy. Another option we have is to do e.g.
#sometag(42)
Scenario: Some scenario
Given something
When something
Then assert
Then report somekey 42
but no solution feels "clean". Is there a canoncal way in Gherkin to accomplish what we are trying to do?
This is no canonical way to associate meta data with scenarios or features. The closest thing you have is tags. There is nothing particularly wrong with using tags. Sure you can filter your tests by tags, but that doesn't mean you cannot make up your own tag format for meta data. You can do additional processing in a before or after scenario callback/hook.
If you do not need to do any processing during a test run, you can always use comments and then make up your own format. You can write a script to parse the comments in the feature files in a custom script, if you want. I'm sure as long as you are consistent it should be fine.
Gherkin language reference: https://cucumber.io/docs/gherkin/reference/#keywords
I have fair understanding on ANTLR & grammar. Is it correct to say ANTLR can do source language to target language conversion like ASP to JSP or COBOL to JSP? if yes, could you help me to provide some information/tutorial/link to explorer the possibilities?
Idea is to pragmatically translating huge amounts of code from source to target using ANTLR.
Thanks
The basic steps to building a translator in Antlr4 is to:
generate a parse tree from an input text in the source language
repeatedly walk the parse tree to analyze the nodes of the parse tree, adding and evolving properties (decorator pattern) associated with individual parse tree nodes -- the properties will describe the change(s) required to represent the content of the node in the target language.
final walk of the parse tree to collect and output the target language text.
The form and content of the properties and the progression of creation and evolution will be entirely dependent on the nature of the source and target languages and the architect's conversion strategy.
Since Antlr parse-tree walks can be logically independent of one another, specific conversion aspects can be addressed in separate walks. For example, one walk can evaluate (possibly among other things) whether individual perform until statements will be converted to if or while statements. Another walk can be dedicated to analyzing variable names to ensure they are created/accessed in the correct scope and determining the naming and scope of any target language required temporary variables. Etc.
Given that the conversion is a one-time affair, there is no fundamental penalty to implementing 5, 10, or even more walks. Just the 'whatever makes sense in your case' practicality.
The (relevant) caveat addressed in the other QA is how to handle conversions where there is no simple or near identity between statements in the two languages. To convert a unique source language statement then requires a target language run-time package be created to implement the corresponding function.
GenPackage (I am the author) automates the generation of a basic conversion project. The generated project represents but one possible architectural approach and leaves substantial work to be done to tailor it to any particular end use.
I am looking to create a Selenium page object for the menu bar of our application. However, the menu items will be different based on the license that the customer has (about 70% will be the same throughout). I am looking at a couple of approaches (I'm using Java):
Create all the methods for all the possible menu items in once class, and then just depend on the test case writer to use the correct methods.
Create a different page object for each different license (about 5 as of right now).
Which one would be better in the long term?
Thanks.
I have the exact same situation for my current job. I use the option #1 as it is the most maintable on the long term. Others solutions will add extra complexity which is not justified.
I'm always testing with "full" licence (the operator can do anything). Then, I have some specific tests to test the GUI is only showing what it is supposed to show with limited licence.
The page object I use will fail if called on a menu that does not exist on the screen (something that turn my test cases red). There are methods on my framework to determine the presence (or not) of a menu.
Note: If you are testing the security of your software (to ensure the operator cannot gain extra access), you need to use other technique. For such test you have to bpass the GUI and "attack" your server directly.
Why not create an enumerator for the license types then pass that enum into your method calls on the Page Object? The method could then use if/else or a switch to return appropriate values or take appropriate action based on the given license.
I suggest to use Java Inheritance
Create a class with the basic account and extend it for complex accounts.
See example here: Java docs: An Example of Inheritance
I want to program a custom version of the predicate cumulative/2 (or at least a similar predicate in terms of functionality). I looked for the sources of CLP(FD) library and I was now wondering whether it could be a good idea to modify that library (only by adding new things) in order to incorporate the new my_cumulative/2 but with the library's private predicates available to do so.
I want to add the following features:
I want the task planner to be preemptive (meaning that planned tasks can be "splitted" in several time intervals).
Apart from being cumulative, I want it to be multi-resource (meaning that instead of [limit(3)] I could have, for instance, [limit(2),limit(3),limit(1)]; where each limit corresponds to a different resource)
I want to add priorities to each task, so that higher priority tasks have more "decision power" and can't be left unscheduled by lower ones.
I want the solution "not-schedulable" to be a possible solution for a task.
This idea came to me when I was trying to add a custom operator /\ to calculate intersections (like-wise \/ denotes unions) and I saw that there actually is one already defined in clpfd.pl but not made part of the module.
For a start, you should try to express your constraints in terms of exported library predicates. If you need to use a private predicate of the library, you can call it with its module prefix (like clpfd:some_predicate(...)). Private predicates may change without notice, but they can be useful if you want to experiment with some things, and you can ask for more public predicates etc. on the SWI mailing list when you have found out which ones are useful to you. To calculate intersections with public predicates, you can use for example: X in 0..5 #/\ X in 0..2, fd_dom(X, Dom). You can use (#\/) for unions.
You can define a new module and within it use the reexport/1 and reexport/2 directives to reexport the full CLP(FD) library or just part of it. In this new module, you can add new stuff or override the existing one if necessary.