Spock label combinations - groovy

There | are | so many | Spock | spec examples of how to use its labels, such as:
// when -> then label combo
def "test something"() {
when:
// blah
then:
// blah blah
}
Such label combinations as:
when -> then
given -> when -> then
expect
given -> expect
But nowhere can I find documentation on what the legal/meaningful combinations of these labels are. For instance, could I have:
def "do something"() {
when:
// blah
expect:
// blah
}
Could I? I do not know. What about:
def "do something else"() {
when:
// blah
then:
// blah
expect:
// blah
where:
// blah
}
Could I? Again, I do not know. But I wonder.

I am actually an author of one of the tutorials you have mentioned. I think the best to answer your question would be to really understand what particular labels are for. Maybe then it would be more obvious why certain combinations make sense and other do not. Please refer to original documentation http://spockframework.github.io/spock/docs/1.0/spock_primer.html. It explains really well all labels and their purpose. Also it comes with this diagram:
Which I hope should already tell you a lot. So for instance having both when and expect labels makes not much sense. The expect label was designed to substitute both when and then. The reasoning behind it is well explained in the documentation:
An expect block [...] is useful in situations where it is more natural to describe stimulus and expected response in a single expression.
Spock itself will not allow you to use this combination. If you try to execute following code.
def "test"() {
when:
println("test")
expect:
1==1
}
You will receive an error message like this.
startup failed:
/Users/wooki/IdeaProjects/mylibrary/src/test/groovy/ExampleTest.groovy:
13: 'expect' is not allowed here; instead, use one of: [and, then] #
line 13, column 9.
To my surprise the second of your examples works. However I believe there is really not much gain of using expect here instead of and as I would normally do.
def "do something else"() {
when:
// stimulus
then:
// 1st verification
and:
// 2nd verification
where:
// parametrization
}
The only reason to have expect or and after then is to separate code responsible for verifying the result of executing the code inside when label. For instance to group verifications that are somehow related to each other, or even to separate single verifications but to have a possibility of giving them a description using strings that can be attached to labels in Spock.
def "do something else"() {
when:
// stimulus
then: "1 is always 1"
1 == 1
and: "2 is always 2"
2 == 2
}
Hence, since you are already stating that verification part of the test began (using then block) I would stick to and label for separating further code.
Regarding where label. It works sort of as a loop indicator. So whatever combinations of labels you use before you could always put at the end the where label. This one is not really a part of a single test run, it just enforces the test to be run a number of times.
As well it is possible to have something like this:
def "test"() {
given:
def value
when:
value = 1
then:
value == 1
when:
value = 2
then:
value == 2
}
Using the above, just make sure that your test is not "testing too much". Meaning that maybe a reason why you use two groups of when-then makes a perfect excuse for this test to be actually split into two separate tests.
I hope this answered at least some of your questions.

Related

How to structure optional parts of a function?

Apologies for the horrible title, but I do not know the proper wording for it, which is part of the problem.
Currently I am making some functions in python with a general structure like this:
def printfunction(parameter1, parameter2, option1=False,option2=False):
print(f"Stuff that always happens+{parameter1}")
if option1 == False and option2 == False:
print(f"Basic Functionality+{parameter2}")
if option1 == True:
print("Option1")
if option2 == True:
print("Option2"
if option1 == True and option2 == True:
print(f"Option 1 and 2+{parameter2}")
So I would like a function that executes it's basic functionality, but if one or multiple of a set of Boolean keywords are set to True, I want it to execute some other functionality (or the original plus some new) and with only 2 "option" keywords the way I did it above works perfectly fine, but if one wants a lot of options like this, the function gets filled with "if option==False/True" statements, making very messy code.
So my question is: Is there a more efficient way of having a function that can execute multiple options? While sharing the initial parameters and some parts of the function.
Or am I just doing this all wrong and should I use a class with different methods?
Thanks in advance for any reply

How to skip a Parameter with Default Values in Groovy?

My Groovy method has 3 parameters and the last 2 have default values. I want to skip the second parameter, and only provide values for the first and the third like so..
def askForADate(girlsName, msg = 'Will you go out with me?', beg = 'pretty please!!') {
println "$girlsName, $msg $beg!"
}
askForADate('Jennifer',,'Because I love you!')
Right now this prints out...
Jennifer, Because I love you! pretty please!!!
So it looks like it is plugging the value I am passing in for the third parameter into the second.
How to fix that?
As doelleri said, you'll need to write two version of thie method.
Unless you'll use some groovy goodness with named arguments!
def askForADate(Map op, girlsName) {
println "$girlsName, ${op.get('msg', 'Will you go out with me?')} ${op.get('beg', 'pretty please!!')}!"
}
askForADate(beg: 'Because I love you!', 'Jennifer')
Prints out: Jennifer, Will you go out with me? Because I love you!!
See http://mrhaki.blogspot.com/2015/09/groovy-goodness-turn-method-parameters.html for more details
This solution has the clear disadvantage of reordering the arguments as now the girls name is last in line.

How to check if the first variable passed into a method is a string. Perl

I have no idea how to check for this. My method(if condition in method) should only work (execute) if the first argument passed in is a string. I know how to check other types, but I can't seem to find anything for checking for a string.
For a hash I would do something like;
if(ref eq 'HASH') {...}
If someone could provide a simple example I'm sure I would be able to apply it to what I'm doing. I will put up the code for the method and an explanation for the whole operational details of the method if needed.
Added Information
This is a method for handling different types of errors in the software, here are the 3 possible input formats:
$class->new("error string message")
$class->new("error string message", code => "UNABLE_TO_PING_SWITCH_ERROR")
$class->new("error string message", code => "UNABLE_TO_PING_SWITCH_ERROR", switch_ip => $ip3, timeout => $timeout)
There will always be an error message string first.
With the 1st case there is also a hashref to an error hash structure that is located in a library,
this method new will go into a template processing if the word "code" exists as an arg. where the longer detailed error message is constructed. (I already have the logic for this).
But I have to add logic so that the error message string is added to the hash, so the output is one hash, and not strings.
The second case is very similar to the first, where there are parameters eg. switch_ip , which are inserted into the string using a similar template processing logic, (already have this too).
So I think the first and second cases can be handled in the same way, but I'm not sure, so separated them in this question.
The last case is just can error message string by itself, which at the minute I just insert it into a one key message hash { message => "error string}.
So after all that how should I be checking or dividing up these error cases, At the minute my idea for the ones with code , is to dump the arguments into a hash and just use something like:
if(exists($param{code}) { doTemplateProcess()...}
I need to ensure that there is a string passed in first though. Which was my original question. Does any of my context information help? I hope I didn't go off the topic of my question, if so I'll open this a new question. Thanks.
Error hash - located in Type.pm
use constant ERROR_CODE => {
UNABLE_TO_PING_SWITCH_ERROR => {
category => 'Connection Error:',
template => 'Could not ping switch %s in %s minutes',
tt => {template => 'disabled'},
fatal => 1,
wiki_page => www.error-solution.com/,
},
}
From comments:
These will be called in the software's code like so
ASC::Builder::Error->new(
"Phase x this occured because y was happening:",
code => UNABLE_TO_PING_SWITCH_ERROR,
switch_ip => $ip3,
timeout => 30,
);
Putting the wisdom of your particular problem aside and channeling Jeff Foxworthy:
If you have a scalar and it's not a reference, you might have a string.
If your non-reference scalar doesn't look like a number, it might be a string.
If your non-reference scalar looks like a number, it can still be a string.
If your non-reference scalar has a different string and number value, it might be a dualvar.
You know that your argument list is just that: a list. A list is a collection of scalar values. A scalar can be a reference or not a reference. I think you're looking for the not a reference case:
die "You can't do that" if ref $first_argument;
Past that, you'd have to do fancier things to determine if it's the sort of value that you want. This might also mean that you reject objects that pretend to be strings through overloading and whatnot.
Perhaps you can make the first argument part of the key-value pairs that you pass. You can then access that key to extract the value and delete it before you use the remaining pairs.
You may easily check only whether the error string is a simple scalar value or a reference. You would do that with ref, but you must consider what you want to do if the first parameter isn't a string
You should write your constructor in the ASC::Builder::Error package along these lines
sub new {
my $class = shift;
my ($error, %options) = #_;
die if ref $error;
bless { string => $error }, $class;
}
This example simply dies, and so kills the program, if it is called with anything other than a simple string or number as the first parameter
You may call it as
ASC::Builder::Error->new('error')
or
ASC::Builder::Error->new(42)
and all will be well. If you try
ASC::Builder::Error->new('message', 'code')
then you will see a warning
Odd number of elements in hash assignment
And you may make that warning fatal
If there is anything more then you should explain
Supporting all of the following is simple:
$class->new("s")
$class->new("s", code => "s")
$class->new("s", code => "s", switch_ip => "s", timeout => "s")
All you need is the following:
sub new {
my ($class, $msg, %opts) = #_;
...
}
You can checks such as the following to examine what the called provided:
if (exists($opts{code}))
if (defined($opts{code}))
if ($opts{code})
Despite saying that the string will always be provided, you now ask how to check if was provided. As such, you are probably trying to perform validation rather than polymorphism. You shouldn't waste your time doing this.
Let's look at the hash reference example you gave. ref($arg) eq 'HASH' is wrong. That returns false for some hash references, and it returns false for some things that act like a reference to a hash. The following is a more proper check:
eval { %$arg; 1 }
The equivalent for strings would be the following:
eval { "$arg"; 1 }
Unfortunately, it will always return true! Every value can act as a string. That means the best thing you can do is simply to check if any argument is provided.
use Carp qw( croak );
croak("usage") if !#_;
It's rare for Perl subs to perform argument validation. Not only is it tricky, it's also expensive. It also provides very little benefits. Bad or missing arguments usually results in exceptions or warnings shortly after.
You might see suggestions to use croak("usage") if ref($arg); (or worse, die if ref($arg);), but keep in mind that those will cause the rejection of perfectly fine objects that overload stringification (which is somewhat common), and they will fail to detect the problem with ASC::Builder::Error->new(code => ...) because code produces a string. Again, performing type-based argument validation is an expensive and buggy practice in Perl.

Does assert.equal offer any advantages over assert (assert.ok)?

In this question I refer to the assert module that is included within the node.js core.
As far as I can tell the following two assertions are pretty much identical:
assert.equal(typeof path, "string", "argument 'path' must be a string");
assert(typeof path === "string", "argument 'path' must be a string");
Upon failure both variations report the same message:
AssertionError: argument 'path' must be a string
Are there any notable advantages of the former over the latter in this situation?
Well, depending on the test runner framework, assert.equal will probably give you a more descriptive error message. For instance, in this case:
assert.equal(typeof path, "string");
assert(typeof path === "string");
the first statement would give you a message along the lines of:
actual: number
expected: string
which already tells you that the test case fails because typeof path is a number.
The latter will only print something like this:
AssertionError: false == true
Also, note that if you want to check for strict equality (===), you should use assert.strictEqual instead of assert.equal.
assert.equal doesn't check for identity, only equality. It's equivalent to:
assert(typeof path == 'string', "argument 'path' must be a string");
The real equivalent would be assert.strictEqual, which uses the identity operator ===:
assert.strictEqual(typeof path, "string", "argument 'path' must be a string");
For typeof, no, there's no difference. You'll run into problems with other data types though:
> assert.equal('test', ['test']);
undefined
> 'test' == ['test']
true
> 'test' === ['test']
false
Both will work.
First, assert uses the coercive == operator, not strict ===
Also, when you read a lot of your unit tests or other people's unit tests, you'll strain your eyes on repetitive syntax. You'll love it when people will write this
assert.equal(aValue, anotherValue) // sexy
/** But you will hate people writing this. **/
assert.ok(aValue == anotherValue) // ugly
In the first case, you can see the condition being checked within the first 9 letters. You don't even need to look further. In the other case, you have to read 20 letters to know what the test is checking. It's more cryptic.
Also, assert.equal is more declarative of your intention than assert.ok.
Imagine you are writing a test for testing a set intersection. You would read better
assert.setIntersect(set1, set2) // wow
assert.ok(setIntersect(set1, set2)); // hm.
To sum it up, the advantage is in readability (thus maintainability) of you unit tests. It's not much, but it helps writing better understandable code.
As alexander said, too, you will have more precise error messages when test fail if you don't specify a message.

Groovy - How can I compare part of a list to a string

I have a list which contains two types of text. One type is used for authorization while other type is used for all other purposes.
The type used for authorization always uses the same text + some code after it.
I would like to compare content of these two types of text and separate them based on content.
My idea is to look for pattern in authorization type and if it matches the pattern then this would be marked as authorization, otherwise it would be marked as "other".
I researched about comparison of patterns in Groovy, but all variations I tried did not work for me. Here is the part which should do the comparison, I am obviously doing something wrong but I don't know what.
jdbcOperations.queryForList(sql).collect { row ->
if(assert (row['MSG'] ==~ /token/)){
mark as authorization
}
else{
mark as other
}
}
Sorry for the vague code, I can not share more than this.
I think you just missing the match for the rest of the text, since you are looking only for the first part to match.
assert ("abc" ==~ /abc/) == true
assert ("abcdefg" ==~ /abc/) == false
assert ("abcdefg" ==~ /abc(.*)/) == true // <--- This can also be made more complicated

Resources