Ok, there is a slight issue with test comparing lists. Atm whenever I compare two identical lists whose only difference is type or nullability it causes an error. For instance:
sys::Str[Daniel Fath, John Doe] != sys::Str?[Daniel Fath, John Doe]
I tried forcefully giving a local variable a Str? type but to no avail. It's not a big issue but it's a definite gotcha for me.
IMHO that should be solved either by having a separate verifyEqContent method or by allowing me to manually override the type in an elegant manner like a Str?[] data := [Daniel Fath, John Doe]
brianMon 9 May 2011
Yes you are correct - list equality does consider type equality as well as the contents.
For testing purposes, I think this is important. If you expect a method to return Str[] and it returns Str?[], then your tests should capture this.
So I personally always explicitly like to see the type in the verifyEq.
me to manually override the type in an elegant manner like a Str?[] data := [Daniel Fath, John Doe]
You just declare your list with a type:
data := Str?[Daniel Fath, John Doe]
DanielFathMon 9 May 2011
Tnx brian. I did solve my problem by making it a field, though your way is better.
DanielFath Sun 8 May 2011
Ok, there is a slight issue with test comparing lists. Atm whenever I compare two identical lists whose only difference is type or nullability it causes an error. For instance:
I tried forcefully giving a local variable a
Str?
type but to no avail. It's not a big issue but it's a definite gotcha for me.IMHO that should be solved either by having a separate
verifyEqContent
method or by allowing me to manually override the type in an elegant manner like aStr?[] data := [Daniel Fath, John Doe]
brian Mon 9 May 2011
Yes you are correct - list equality does consider type equality as well as the contents.
For testing purposes, I think this is important. If you expect a method to return
Str[]
and it returnsStr?[]
, then your tests should capture this.So I personally always explicitly like to see the type in the verifyEq.
You just declare your list with a type:
DanielFath Mon 9 May 2011
Tnx brian. I did solve my problem by making it a field, though your way is better.