I wonder if anyone would know how this can be done.
I have a scenario that goes something like the following snippet. Within the table, I would like to have parameters that can be substituted when the test is run. Example snippet:
...
Given blah blah blah
Then yada yada yada
...
And the quotes should have details:
|Ref|Product|Issue Date|Maturity Date|
|<A VALID REF>|Vanilla Option|<TODAY>|<TODAY+3M>
So what I would like to know is whether JBheave supports this kind of parameterisation within a table where I can define a value for and somewhere in the code and have it substituted at runtime.
I find no documentation that refers to this, so I suspect that I would have to do it manually. That's no problem really, but if there's a better way to do it then I'd be keen to learn.
I haven't played with JBehave for a while (since 2.X) but it didn't support it then and I think it's unlikely to support it now.
What you're doing here is crafting a scenario which works for all examples. That's not really a scenario - it's acceptance criteria, written in scenario form. If you do this, you'll miss out on the other benefits of using concrete examples, particularly in the way that they excite the imagination, call out the interesting behavior and allow useful questions and conversations with business stakeholders.
In this case, if the product is the most interesting thing about the outcome of this scenario, the better thing to do is to call it out separately, e.g.
Then the quotes should contain the Vanilla Option product.
Even more powerful would be to work out who the outcome is useful for, and mention in what way it's useful, e.g.
Then the user should receive a quote by email to entice them to buy the Vanilla Option.
Notice that in the example I've given it's actually the business that benefits, and it's not really done for the user.
By making the steps at a higher level of abstraction you'll find it easier to call out the value of the outcome to the users / stakeholders, which will help you have better conversations. Conversation, not automation, is at the heart of BDD.
This is why I don't believe JBehave supports it, nor do I think it should.
I think that this is what you are trying to do.
I use a lot of random data in my tests, for example, for people's names. When I generate the random name I write it to a Java class for storing this type of data which I can then recall later on.
In the story I will have something like
When I create a new customer <customer>
When I do some stuff
When I do some more customer stuff
|NAME |VALUE |
|custName|<CUSTNAME>|
|dob |01/01/1970|
When I do some more stuff
Examples:
|<customer>|<BLAH1>|<BLAH2>|<CUSTNAME>|<BLAH4>|
|\$random |para1 |para2 |\$name |para4 |
|George |para1 |para2 |Peter |para4 |
In the class where the data is extracted from the table I use:
if (value.equalsIgnoreCase("$name") {
this.value = getStoredData().getName();
} else {
this.value = value;
}
It is my own personal convention that I use <> around variables within the story and $ for variables where the Java code generates or recalls the value of the variable.
If you use $ in the Examples table it has to be escaped, hence the back slash
Related
According to protobuf documentation
Repeated fields have some extra methods – a Count method
so something like this:
// repeated .tutorial.Person.PhoneNumber phone = 4;
public List<PhoneNumber> getPhoneList();
public int getPhoneCount();
public PhoneNumber getPhone(int index);
Is it possible to suppress the generation of getPhoneCount? I don't want it in the resulting java class. Is it possible to not generate it?
EDIT: To make clear what my problem is, we have .proto file with something like this
message Bar {
...
optional int32 entries_count = 123
...
repeated Foo entries = 456
...
}
Because of that, both entries_count and entries tries to generate function getEntriesCount(), which is obviously not possible. So it's generated instead as getEntriesCount123() and getEntriesCount456(), which is not exactly user friendly. So I would like to suppress generation of one of them, since they are supposed to return same value anyway.
Sadly I'm not really sure how feasible is changing the format, too many things around may depend on it :/
No, there's no way of doing this.
If you look at the generator code (primitive fields, message fields, enum fields etc) you can see that the ...Count() methods (both interface and implementation) are written unconditionally.
Options:
Live with the existing generation code
Use your own fork of protoc
Create a pull request for the main project
I'd strongly recommend option 1. With option 2 you'll be forever having to do work to keep it up to date, and I'd be quite surprised if you managed to get option 3 accepted into the codebase... the bar for adding an extra option is pretty high.
Basically, you should remove your entries_count field. It's an obvious place where data can get out of sync - and the real value is always available to clients anyway, in all platforms I'm aware of. If you want it to mean something other than just "the number of values in entries" (e.g. some estimated total count, where you've only got some sample) then you should rename it to be more specific, at which point your existing problem will go away at the same time.
I'm a StringTemplate newbie with a really basic. I'm trying to utilize this to send automated emails. I've read as much as I can to digest what is out there. I'm starting with a simple test case and having trouble getting properties of objects to render. As a test case I have the following in my template file email.stg.
delimiters "$", "$"
activate(person) ::= <<$person.personFirstName$>>
I'm trying to pass my Person object and have the template render the personFirstName property. This would call a getter Person.personFirstName() which is public.
My java code looks like:
Person _thePerson = //fetched from database
STGroup group = new STGroupFile(/tmp/email.stg);
ST st = group.getInstanceOf("activate");
st.add("person", _thePerson);
System.out.println("the person first name is: " + _thePerson.personFirstName());
System.out.println(st.render());
My output reflects that the personFirstName property is available via java but my template does not render it.
the person first name is: Ivan
<nothing is returned here>
If I limit the activate template to this:
activate(person) ::= <<$person$>>
I get the following result where the person object is rendered as _thePerson.toString().
the person first name is: Ivan
999999999 - Johnson, Ivan G
Any help would be greatly appreciated so I can move on to the more complex template that I'm trying to get to.
Answering my own question: I think this is the answer from the Introduction here - https://theantlrguy.atlassian.net/wiki/display/ST4/Introduction.
"...in general they follow the old JavaBeans naming convention. StringTemplate looks for methods getP(), isP(), hasP() first. If it fails to find one of those methods, it looks for a field called p."
I took that to mean that "p" would work as a method name as well but was wrong. I'm using Enterprise Object Framework and, unfortunately, my model .java files' attribute accessors do not use the "get*" convention which means ST never requests them. They are also not stored as fields. I'll have to think of a way around it but I don't think I'm inclined to change large scale model frameworks to accommodate this. If I add cover (get*) methods it works but that is not the best solution.
Generally, I've never encountered this issue since WebObjects template engine will render with or without "get*."
I've got a bit of an interesting challenge
To the point:
I want to allow a user to enter an expression in a text field, and have that string treated as a python expression. There are a number of local variables I would like to make available to this expression.
I do have a solution though it will be cumbersome to implement. I was thinking of keeping a Python class source file, with a function that has a single %s in it. When the user enters his expression, we simply do a string format, and then call Jython's interpreter, to spit out something we can execute. There would have to be a number of variable declaration statements in front of that expression to make sure the variables we want to expose to the user for his expression.
So the user would be presented with a text field, he would enter
x1 + (3.5*x2) ** x3
and we would do our interpreting process to come up with an open delegate object. We then punch the values into this object from a map, and call execute, to get the result of the expression.
Any objections to using Jython, or should I be doing something other than modifying source code? I would like to think that some kind of mutable object akin to C#'s Expression object, where we could do something like
PythonExpression expr = new PythonExpression(userSuppliedText)
expr.setDefaultNamespace();
expr.loadLibraries("numPy", /*other libraries?*/);
//comes from somewhere else in the flow, but effectively we get
Map<String, Double> symbolValuesByName = new HashMap<>(){{
put("x1", 3.0);
put("x2", 20.0);
put("x3", 2.0);
}};
expr.loadSymbols(symbolValuesByName);
Runnable exprDelegate = expr.compile();
//sometime later
exprDelegate.run();
but, I'm hoping for a lot, and it looks like Jython is as good as it gets. Still, modifying source files and then passing them to an interpreter seems really heavy-handed.
Does that sound like a good approach? Do you guys have any other libraries you'd suggest?
Update: NumPy does not work with Jython
I should've discovered this one on my own.
So now my question shifts: Is there any way that from a single JVM process instance (meaning, without ever having to fork) I can compile and run some Python code?
If you simply want to parse the expressions, you ought to be able to put something together with a Java parser generator.
If you want to parse, error check and evaluate the expressions, then you will need a substantial subset of the functionality a full Python interpreter.
I'm not aware of a subset implementation.
If such a subset implementation exists, it is unclear that it would be any easier to embed / call than to use a full Python interpreter ... like Jython.
If the powers that be dictate that "thou shalt use python", then they need to pay for the extra work it is going to cause you ... and the next guy who is going to need to maintain a hybrid system across changes in requirements, and updates to the Java and Python / Jython ecosystems. Factor it into the project estimates.
The other approach would be to parse the full python expression grammar, but limit what your evalutor can handle ... based on what it actually required, and what is implementable in your project's time-frame. Limit the types supported and the operations on the types. Limit the built-in functions supported. Etcetera.
Assuming that you go down the Java calling Jython route, there is a lot of material on how to implement it here: http://www.jython.org/jythonbook/en/1.0/JythonAndJavaIntegration.html
Is there any way of inserting code at runtime to log return values, for instance, using instrumentation?
So far, I managed to insert code when a method exits, but I would like to log something like "method foo returned HashMap { 1 -> 2, 2 -> 3 }"
I'm looking for a general approach that can also deal with, for instance, java.io.* classes. (So in general I'll have no access to the code).
I tried using a custom classloader too, but lot of difficulties arise as I cannot modify java.* classes.
Thanks for the help!
Sergio
Check out BTrace. It's Java, and I believe it'll do what you want.
Have you considered AOP? (Aspect-oriented programming) - if by "I cannot modify java.* classes" you mean you don't have access to the uncompiled code, and cannot add configuration, etc., then that won't probably work for you. In any other case, check that link for examples using Spring-aop:
http://static.springsource.org/spring/docs/2.5.x/reference/aop.html
If not, you could consider solutions based on remote-debugging, or profiling. But they all involve "some" access to the original code, if only to enable / disable JMX access.
Well, since you're looking for everything, the only thing I can think off is using a machine agent. Machine agents hook into the low levels of the JVM itself and can be used to monitor these things.
I have not used DTrace, but it sounds like it would be able to do what you need. Adam Leventhal wrote a nice blog post about it. The link to DTrace in the blog is broken, but I'm sure a quick search and you'll come up with it.
Take a look at Spring AOP, which is quite powerful, and flexible. To start you off on the method foo, you can apply an AfterReturning advice to it as:
#Aspect
public class AfterReturningExample {
#AfterReturning(
pointcut="package.of.your.choice.YourClassName.foo()",
returning="retVal")
public void logTheFoo( Object retVal ) {
// ... logger.trace( "method 'foo' returned " + retVal ); // might need to convert "retVal" toString representation if needed
}
}
The pointcut syntax is really flexible so you can target all the sub packages, components, methods, return values given the expression.
I need to change the signature of a method used all over the codebase.
Specifically, the method void log(String) will take two additional arguments (Class c, String methodName), which need to be provided by the caller, depending on the method where it is called. I can't simply pass null or similar.
To give an idea of the scope, Eclipse found 7000 references to that method, so if I change it the whole project will go down. It will take weeks for me to fix it manually.
As far as I can tell Eclipse's refactoring plugin of Eclipse is not up to the task, but I really want to automate it.
So, how can I get the job done?
Great, I can copy a previous answer of mine and I just need to edit a tiny little bit:
I think what you need to do is use a source code parser like javaparser to do this.
For every java source file, parse it to a CompilationUnit, create a Visitor, probably using ModifierVisitor as base class, and override (at least) visit(MethodCallExpr, arg). Then write the changed CompilationUnit to a new File and do a diff afterwards.
I would advise against changing the original source file, but creating a shadow file tree may me a good idea (e.g. old file: src/main/java/com/mycompany/MyClass.java, new file src/main/refactored/com/mycompany/MyClass.java, that way you can diff the entire directories).
Eclipse is able to do that using Refactor -> Change Method signature and provide default values for the new parameters.
For the class parameter the defaultValue should be this.getClass() but you are right in your comment I don't know how to do for the method name parameter.
IntelliJ IDEA shouldn't have any trouble with this.
I'm not a Java expert, but something like this could work. It's not a perfect solution (it may even be a very bad solution), but it could get you started:
Change the method signature with IntelliJ's refactoring tools, and specify default values for the 2 new parameters:
c: self.getClass()
methodName: Thread.currentThread().getStackTrace()[1].getMethodName()
or better yet, simply specify null as the default values.
I think that there are several steps to dealing with this, as it is not just a technical issue but a 'situation':
Decline to do it in short order due to the risk.
Point out the issues caused by not using standard frameworks but reinventing the wheel (as Paul says).
Insist on using Log4j or equivalent if making the change.
Use Eclipse refactoring in sensible chunks to make the changes and deal with the varying defaults.
I have used Eclipse refactoring on quite large changes for fixing old smelly code - nowadays it is fairly robust.
Maybe I'm being naive, but why can't you just overload the method name?
void thing(paramA) {
thing(paramA, THE_DEFAULT_B, THE_DEFAULT_C)
}
void thing(paramA, paramB, paramC) {
// new method
}
Do you really need to change the calling code and the method signature? What I'm getting at is it looks like the added parameters are meant to give you the calling class and method to add to your log data. If the only requirement is just adding the calling class/method to the log data then Thread.currentThread().getStackTrace() should work. Once you have the StackTraceElement[] you can get the class name and method name for the caller.
If the lines you need replaced fall into a small number of categories, then what you need is Perl:
find -name '*.java' | xargs perl -pi -e 's/log\(([^,)]*?)\)/log(\1, "foo", "bar")/g'
I'm guessing that it wouldn't be too hard to hack together a script which would put the classname (derived from the filename) in as the second argument. Getting the method name in as the third argument is left as an exercise to the reader.
Try refactor using intellij. It has a feature called SSR (Structural Search and Replace). You can refer classes, method names, etc for a context. (seanizer's answer is more promising, I upvoted it)
I agree with Seanizer's answer that you want a tool that can parse Java. That's necessary but not sufficient; what you really want is a tool that can carry out a reliable mass-change.
To do this, you want a tool that can parse Java, can pattern match against the parsed code, install the replacement call, and spit out the answer without destroying the rest of the source code.
Our DMS Software Reengineering Toolkit can do all of this for a variety of languages, including Java. It parses complete java systems of source, builds abstract syntax trees (for the entire set of code).
DMS can apply pattern-directed, source-to-source transformations to achieve the desired change.
To achieve the OP's effect, he would apply the following program transformation:
rule replace_legacy_log(s:STRING): expression -> expression
" log(\s) " -> " log( \s, \class\(\), \method\(\) ) "
What this rule says is, find a call to log which has a single string argument, and replace it with a call to log with two more arguments determined by auxiliary functions class and method.
These functions determine the containing method name and containing class name for the AST node root where the rule finds a match.
The rule is written in "source form", but actually matches against the AST and replaces found ASTs with the modified AST.
To get back the modified source, you ask DMS to simply prettyprint (to make a nice layout) or fidelity print (if you want the layout of the old code preserved). DMS preserves comments, number radixes, etc.\
If the exisitng application has more than one defintion of the "log" function, you'll need to add a qualifier:
... if IsDesiredLog().
where IsDesiredLog uses DMS's symbol table and inheritance information to determine if the specific log refers to the definition of interest.
Il fact your problem is not to use a click'n'play engine that will allow you to replace all occurences of
log("some weird message");
by
log(this.getClass(), new Exception().getStackTrace()[1].getMethodName());
As it has few chances to work on various cases (like static methods, as an example).
I would tend to suggest you to take a look at spoon. This tool allows source code parsing and transformation, allowing you to achieve your operation in a -obviously code based- slow, but controlled operation.
However, you could alos consider transforming your actual method with one exploring stack trace to get information or, even better, internally use log4j and a log formatter that displays the correct information.
I would search and replace log( with log(#class, #methodname,
Then write a little script in any language (even java) to find the class name and the method names and to replace the #class and #method tokens...
Good luck
If the class and method name are required for "where did this log come from?" type data, then another option is to print out a stack trace in your log method. E.g.
public void log(String text)
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw, true);
new Throwable.printStackTrace(pw);
pw.flush();
sw.flush();
String stackTraceAsLog = sw.toString();
//do something with text and stackTraceAsLog
}