When using the White Box method of testing called Multiple Condition Coverage, do we take all conditional statements or just the ones with multiple conditions? Now maybe the clues in the name but I'm not sure.
So if I have the following method
void someMethod()
{
if(a && b && (c || (d && e)) ) //Conditional A
{
}
if(z && q) // Conditional B
{
}
}
Do I generate the truth table for just "Conditional A", or do I also do Conditional B?
Thanks,
I might be missing something here but, the way you wrote the code in your question, conditions A and B are completely independent of each other. You therefore won't cover all of the code unless you test both conditionals.
I found the following on Multiple condition coverage. This would seem to indicate that Multiple Condition Coverage, as the name suggests, only applies to conditionals with multiple statements.
So for the following conditional:
if ((a>0)&&(b<=4)&&(c>0))
We create the following
Test Case a > 0 b <= 4 c > 0
MCC1 F F F
MCC2 F F T
MCC3 F T F
MCC4 F T T
MCC5 T F F
MCC6 T F T
MCC7 T T F
MCC8 T T T
Related
Isn't order of execution generally from left to right in Raku?
my #a = my #b = [9 , 3];
say (#a[1] - #a[0]) == (#b[1] R- #b[0]); # False {as expected}
say (#a.pop() - #a.pop()) == (#b.pop() R- #b.pop()); # True {Huh?!?}
This is what I get in Rakudo(tm) v2020.12 and 2021.07.
The first 2 lines make sense, but the third I can not fathom.
It is.
But you should realize that the minus infix operator is just a subroutine under the hood, taking 2 parameters that are evaluated left to right. So when you're saying:
$a - $b
you are in fact calling the infix:<-> sub:
infix:<->($a,$b);
The R meta-operator basically creates a wrap around the infix:<-> sub that reverses the arguments:
my &infix:<R->($a,$b) = &infix:<->.wrap: -> $a, $b { nextwith $b, $a }
So, if you do a:
$a R- $b
you are in fact doing a:
infix:<R->($a,$b)
which is then basically a:
infix:<->($b,$a)
Note that in the call to infix:<R-> in your example, $a become 3, and $b becomes 9 because the order of the arguments is processed left to right. This then calls infix:<->(3,9), producing the -6 value that you would also get without the R.
It may be a little counter-intuitive, but I consider this behaviour as correct. Although the documentation could probably use some additional explanation on this behaviour.
Let me emulate what I assumed was happening in line 3 of my code prefaced with #a is the same as #b is 9, 3 (big number then little number)
(#a.pop() - #a.pop()) == (#b.pop() R- #b.pop())
(3 - 9) == (3 R- 9)
( -6 ) == ( 6 )
False
...That was my expectation. But what raku seems to be doing is
(#a.pop() - #a.pop()) == (#b.pop() R- #b.pop())
#R meta-op swaps 1st `#b.pop()` with 2nd `#b.pop()`
(#a.pop() - #a.pop()) == (#b.pop() - #b.pop())
(3 - 9) == (3 - 9)
( -6 ) == ( -6 )
True
The R in R- swaps functions first, then calls the for values. Since they are the same function, the R in R- has no practical effect.
Side Note: In fuctional programming a 'pure' function will return the same value every time you call it with the same parameters. But pop is not 'pure'. Every call can produce different results. It needs to be used with care.
The R meta op not only reverses the operator, it will also reverse the order in which the operands will be evaluated.
sub term:<a> { say 'a'; '3' }
sub term:<b> { say 'b'; '9' }
say a ~ b;
a
b
ab
Note that a happened first.
If we use R, then b happens first instead.
say a R~ b;
b
a
ba
The problem is that in your code all of the pop calls are getting their data from the same source.
my #data = < a b a b >;
sub term:<l> { my $v = #data.shift; say "l=$v"; return $v }
sub term:<r> { my $v = #data.shift; say "r=$v"; return $v }
say l ~ r;
l=a
r=b
ab
say l R~ r;
r=a
l=b
ab
A way to get around that is to use the reduce meta operator with a list
[-](#a.pop, #a.pop) == [R-](#a.pop, #a.pop)
Or in some other way make sure the pop operations happen in the order you expect.
You could also just use the values directly from the array without using pop.
[-]( #a[0,1] ) == [R-]( #a[2,3] )
Let me emulate what happens by writing the logic one way for #a then manually reversing the operands for #b instead of using R:
my #a = my #b = [9 , 3];
sub apop { #a.pop }
sub bpop { #b.pop }
say apop - apop; # -6
say bpop - bpop; # -6 (operands *manually* reversed)
This not only appeals to my sense of intuition about what's going on, I'm thus far confused why you were confused and why Liz has said "It may be a little counter-intuitive" and you've said it is plain unintuitive!
i would be grateful if somebody could help me with this problem. The book I am currently reading has a question
Q What will be the output?
#include <stdio.h>
void main()
{
int a = 3, b = 2;
a = a ==b==0;
printf("%d, %d",a,b);
}
The answer is given as
1,2 ( even on codeblocks got the same answers)
Now i understand that equality operator has precedence over the assignment operator.
So it must be a== b or b == 0 first
Then as both the above have the same operator, The associativity rule causes
a == b to be evaluated first.
But from here on I am lost!
How does one get to 1 and 2 as the answer?
See https://en.cppreference.com/w/cpp/language/operator_precedence
Note the line that says, "Operators that have the same precedence are bound to their arguments in the direction of their associativity." You can see the associativity for each operator on the far right column.
Note that equality operator is on line 10, with associativity left-to-right.
Note that assignment is line 16, so it has lower precedence than equality.
// original
a = a == b == 0
// precedence rule
a = (a == b == 0)
// associativity rule
a = ((a == b) == 0)
I believe that the equality operator does does not have precedence over the assignment operator. C just works itself from left to right.
in
a = a == b == 0;
a is assigned to everything on the right of the equal sign.
On the right side of the equal sign, a == b is evaluated to false. Then we compare equality of the answer to a==b with 0. In c, 0 is equal to false, so we get true. This is our answer to "everything to the right of the equal sign". So then, we assign that value(true) to a, which is an integer. Because of automatic conversion, true is converted to 1 and assigned to a. Now a equals 1.
As an equation, the above process can be represented as: a = (( a == b ) == 0)
Hope this makes sense. Tell me if I need to clarify further.
I was working on making a game, and I was wondering why the construct with the == operator doesn't work while the lower one does. I used an NSLog message afterwards to test.
if (pipe.position.x == bird.position.x){ no idea why this doesn't work
if ((pipe.position.x <= bird.position.x) & (pipe.position.x > bird.position.x - 1)){
This is because one (or both) of the position.x's are a floating-point2 value with a non-zero difference1 between the two position values such that only the second condition is true.
Since p <= b is true for all values that make p == b true, to see why this works "unexpectedly" let's choose some values such that the expression p == b is false2 yet p < b is true and p > b - 1 is true.
Given p = 3.2 (pipe) and b = 3.7 (bird), as an example, then
p == b
-> 3.2 == 3.7
-> false
but
(p <= b) & (p > b - 1)
-> (3.2 <= 3.7) & (3.2 > 3.7 - 1)
-> (3.2 <= 3.7) & (3.2 > 2.7)
-> true & true
-> true
Instead, to detect when the bird "is crossing" the pipe, assuming that x increases to the right, consider
// The bird's head to the "right" of the pipe leading edge..
bird_x >= pipe_x
// ..but bird's butt is not to the "right" of the pipe trailing edge.
// (Also note use of the &&, the logical-AND operator)
&& (bird_x - bird_width <= pipe_x + pipe_width)
Of course, using a non-rectangle (or forgiving overlap) collision detection would lead to less frustrating flapping!
1 This issue occurs because there are some particular floating-point values (but there are no integer values) which can cause the observed effect.
First, reiterate the assumption that p is not equal to b, given that the first condition does not succeed. Let's suppose then that p <= b is written as p == b || p < b but since p == b is false , we can write it as p < b by tautology.
Since both clauses in the second condition are true (such that true && true -> true), we have the rules: 1) p < b is true, and 2) p > b - 1 is true.
Rewriting p < b as p - b < 0 and p > b - 1 as p - b > -1, and then replacing p - b with x yields: x < 0 and x > -1. However, there is no integer value of x which satisfies -1 < x < 0.
(In first section, where p = 3.2 and b = 3.7, x = (p - b) = 0.5 which satisfies the given constraints when x is not restricted to an integer value.)
2 With all above aside, it is possible for p and b to be "very close but different" floating-point values such that there is a non-zero difference between them - due to rounding, they may even be displayed as the same integer value! See How dangerous is it to compare floating point values? and related questions for the cause and "odd" behavior of such when using ==.
If this is the case then round to integer values and use an integer comparison, or; rely entirely on relational comparison such as shown in the proposed condition, or; use epsilon comparison for "nearly equal" of floating-point values.
if you choose abs(pipe.position.x) == abs(bird.position.x) the first condition may satisfy.
I'm trying the following condition, the compiler give no warning but the code does not seems to work. Should This work?
if (self.finishLine > hero.position.y > self.startHeight)
{
hero.position = CGPointMake( hero.position.x + translation.x, hero.position.y);
}
Comparison operators return boolean values.
(self.finishLine > hero.position.y > self.startHeight)
-> ((self.finishLine > hero.position.y) > self.startHeight)
-> ((<0 or 1> > self.startHeight)
I doubt that self.startHeight is ever less than 1, let alone less than 0.
The correct form in C is:
((self.finishLine > hero.position.y) && (hero.position.y > self.startHeight))
I have not tried it but I believe it is a valid expression. AFAIK Objective C does not support sandwiches..
(a > b > c) should evaluate to TRUE or FALSE respectively YES or NO. But how? The compiler would start from left to right here as all operators are equal. (a > b) will evaluate to YES or NO. Those are internally represented by 1 and 0. 1 and 0 may be larger than c or not.
I wonder if the compiler throws a warning at least.
Did you go for it and tried it?
Certain languages like awk script allow for conditional assignments. For example, say you had a list file in the format:
<item name, no spaces> <price as float>
e.g.
Grape 4.99
JuicyFruitGum 0.45
Candles 5.99
And you wanted to tax everything over $1... you could use the awk script:
awk '{a=($2>1.00)?$2*1.06:$2; print a}' prices.data
...which uses conditional assignment to shorten the syntax.
But say you wanted to also offer $1 off all items over $20 and $2 off items over $40. Well in a language like c you would typically do something like:
if (price > 40.00) {
price-=2;
price *= 1.06;
}
else if ( price > 20.00 && price <= 40.00 ) {
price--;
price *= 1.06;
}
else if ( price > 1.00 ) {
price*=1.06;
}
... well I discovered you could kludge awk or other scripting languages into COMPOUND assignment. e.g.:
awk '{a=($2>1.00)?($2>20.00)?($2-1)*1.06:($2>40.00)?($2-2)*1.06:$2*1.06:$2; print a}' prices.data
My questions are that
a) is compound assignment (like this) generally universally compatible with scripting languages that support conditional assignment?
b) Is there a non-kludge way to do multi-conditional assignment in awk script?
To clarify: I am talking exclusively about the shorthand for assignment (<...>?<...>:<...>;, not traditional conditional assignment, which I already know how to do c-like compound assignment for in Awk script. As a side note, as to why I might use shorthand, I think the merit is obvious -- that it's short. But like regexes, you might want to write a good description of what your confusing syntax does for posterity's sake.
a)
Bash, ksh and zsh support compound conditional (ternary) operators (Bash doesn't do floats, though):
for i in {3..5}; do for j in {2..6}; do for k in {2..4}; do
(( a = i > j ? i > k ? j > k ? i * j : i * k : j * k : 0 ))
echo $a
done; done; done
PHP's ternary operator syntax is similar.
Python's is quite different:
a = b if c else d if e else f if g else h
Bash, et al, and Ruby (which also supports the ?: form) support this style (showing Bash's version):
[[ condition ]] && do_if_true || do_if_false
which can be done in a compound form. This can perform actions in addition to assignments.
b) no, not without explicit if/else (or resorting to even more kludginess creativity.
Actually, C has the ? operator too, so you could do the same (fugly) thing with C.
However, you are essentially making write-only code there. If you hadn't told me what that awk statement did, it would be very difficult to figure it out. Why not just go ahead and use if?
You'll thank yourself in 6 months when you discover a need to tweak it.
(a) I think so
(b) Yes
As it happens, your "C" code is almost legal awk. The following slightly tweaked version works just fine as an awk program...
/./ {
price = $1
if (price > 40.00) {
price -= 2
price *= 1.06
} else if ( price > 20.00 && price <= 40.00 ) {
price--
price *= 1.06
} else if ( price > 1.00 ) {
price *= 1.06
}
printf("%6.2f\n", price)
}
I took the semicolons out, but nothing bad happens if you leave them in...