>>Brian Vanpee: Hello, everyone.
My name is Brian Vanpee.
I am a senior test engineer extraordinaire here at Google.
And I'm going to take 15 minutes of your time to talk about the quirkier side of testing.
Quick fun fact about me.
I'm an identical twin.
So if you want to come talk to me later, memorize the shirt I'm wearing.
[ Laughter ] What is a quirk?
So a quirk is an odd trait or behavior.
So -- there we go.
So here are some examples.
So cats that have two different color eyes because of a genetic mutation.
Some people sort of build careers out of being quirky.
This slide you see before you are actually in themselves quirky, because one of them's
a Quark, not a quirk.
Program languages have quirks.
And that's what we're mostly going to talk about today.
A few examples.
Objective-C. Has anyone coded in Objective-C before?
Quite a few of you.
Did you know that there's a property called HM characteristic value lock mechanism last
known action unsecured using physical movement exterior?
[ Laughter ] This -- Objective-C is very verbose.
It's very quirky.
This is 87 characters of greatness.
There's also an interior, in case anyone was curious.
JavaScript is everyone's sort of favorite language to pick on, so, of course, we'll
do that.
So null equals equals undefined.
Does it?
It turns out, yes, null is, in fact, undefined.
Makes sense.
Is null finite?
It turns out that, yes, null is, of course, finite.
Is undefined finite?
No.
Because of course not.
They're equal, but they're not the same.
So that's another sort of quirk you see quite a bit in languages.
That's why (indiscernible) a lot of languages sort of introduce the triple equals operator
that say that it's not just equal in value, but also in type as well.
So null and undefined are the same value, in quotes, but not the same type.
JavaScript's fun, so we'll keep going.
Which is larger, 3 or 0?
Hands up if you think it's 0.
The answer is 3.
Makes sense.
But what's greater, 3 or true?
3 is always greater than the truth.
Remember that.
[ Laughter ] What's larger, negative 1 or an array of 1?
An array of 1, because in JavaScript, the value of an array is the value of the first
element.
Makes sense.
We can keep going all day, of course.
What's larger, negative 1 or the empty set?
0.
[ Laughter ] We all saw that coming.
What's greater, negative 1 or undefined?
Not a number.
Not a number is greater than -- that doesn't even make sense.
Which is larger, negative 1 or null?
Turns out the answer is 0.
One thing you'll notice is, null is pretty much 0 for all intents and purposes.
So if you take a value -- take null, add 1 to it, the answer you get is 1.
Great.
So some quirks are found in many languages.
Here's an example in Java.
So if I were to say, print my name, but with a nice fancy "B" on top, and then I get fancy
and I'm going to make it all uppercase, it turns out what that actually does is that
not only changes the value of the string, but changes the length of the string.
So a little tidbit there.
When you're doing testing, you always be careful about changing case when you're using Unicode
characters.
The two often don't mix, FYI.
Some quirks are specific -- and I lost my slides.
Some quirks are specific to languages.
And we'll pause here.
I will pause to take
a drink.
There we go.
As I was saying -- none of that just happened -- some quirks are specific to a specific
language.
So here's an example in Java as well.
So if I were to write A increment -- post increment operator is the new A post increment
operator, the answer, of course, is 0 is the new 1, because it takes A, prints it, then
increments it.
Takes A, prints it, then increments it.
So 0's the new 1.
A is now 2. Make sense?
If you do the exact same thing in C++, 0 is the new 1?
No. 1 is the new 0.
That's weird.
Of course, here's the C equivalent.
It does the same thing.
So, any sort of C variant does something weird that's not the same as Java.
Why is this?
So it has to do with sequence points.
So, sequence points are defined in C as a point in time at which side effects have been
guaranteed so far to be complete.
And they vary from language to language.
As you can see, Java and C++ are different because of sequence points.
C also defines that between the previous and (indiscernible) and objects will have a stored
value modified it most once.
So as you saw, we modified it once.
Then when we tried to modify it again, it had no effect because of sequence points.
So, again, our example, 1 is the new 0 because A was incremented once and you can't increment
it twice in the same -- between two (indiscernible) points.
So that's why that works.
In fact, if you increment B a whole bunch of times, it will never actually increment,
because this is equivalent -- if you do B, it was B++, it's actually not valid in C or
C++, because what you're essentially saying is, B equals B. Then we increment it, but
it's not assigned.
Again, these are all sort of very in-depth about the post increment operator.
The preincrement operator does work as expected, because, of course, it increments, then it
does the assignment.
Wonderful.
But this is the interactive portion of the talk.
So I hope you're all not too full from lunch.
So finding the quirk is all the fun, so I'm going to throw some examples at you and I'm
going to see if you can guess what the quirk is.
So, can anyone tell me what this does?
Any guess?
Returns 1, I heard?
Well, it returns 1, 2, 3, or doesn't compile.
Those are your options.
It turns out that has to do with the comma operator.
So, in many languages, the comma operator says, always evaluate the left-hand side,
then always evaluate the right-hand side, no matter what.
And, of course, as opposed to the "and" operator, which does one or the other and "or" as well
as well.
Not every comma is an operator, but you may have seen this before, for example, in four
loops when you've seen this sort of syntax.
So in this case, it returns the value 3, because it evaluates 1, evaluates 2, and then it returns
3, because the results of the expression is 3.
Does anyone know what this does?
It returns 3, which makes sense, because, just because I threw in some brackets in there
doesn't mean I fool you; right?
Does anybody know what this does?
This, of course, also returns 3.
You're starting to see the pattern here, because the value in an expression is the expression.
So does anyone know what this does?
That's a syntax error.
That does nothing.
[ Laughter ] Can anyone give me a value for "I" that makes
this statement true?
What value is equal to its own negative?
0.
I heard 0.
Very well done.
Not every quirk is a trick.
In all these languages here, 0 works.
But is there a value for I that is not 0 that is also true?
Sorry.
Was there a guess?
Not a number?
Close.
Integer dot int value.
That's a little weird.
Why is that?
If you remember, most languages that treat integers as a 32-bit number, the range is
negative 231 to positive 231 minuse 0.
So there's actually one more positive -- negative number than there is positive numbers.
So you take, for example, a negative number, which is, you know, 8 with a bunch 8 -- 8
(indiscernible) with a bunch of zeroes, and then you negate that, that's equivalent to
saying, take the integer max value, add 1 to it, and it turns out it's the same value.
So long story short, integer (indiscernible) min value is its own negation.
Fancy trick.
Always be careful, and especially when you're dealing with rollover situations.
Gets you every time.
Is there any value that's equal to itself plus 1?
Sorry.
Any guesses?
Infinity?
That's a great guess.
And it turns out it's right.
This is simple math.
So any language that implements the 754 floating point spec defines an infinity value.
So, of course, infinity plus 1 is just infinity.
Makes sense.
Does anybody know a value for I that is not equal to itself?
Is this even possible?
It is possible, someone says?
What value?
>>> (Off mic.)
>>Brian Vanpee: Not a number.
That's an excellent guess.
Turns out it's correct.
Again, 752 [sic] floating point spec, there's a lot of detail in there, but the key is,
there is no -- excuse me.
The spec defines not a number to be equal to nothing, not even itself, no matter what.
Can anyone tell me what this does?
So here's a quick show of hands.
Has anybody seen the approaches operator before in any language?
That's because it doesn't exist, of course.
So the trick to this is most people are probably thinking the first line, you've got it.
It's equivalent to saying five minus negative negative negative negative negative six, which
is, of course, the value 11.
The approaches operator is actually equivalent to i minus minus is greater than one.
The trick here is that -- and of course never do this, is that it doesn't matter how you
write and how spacing works as long as it's parsable.
So as long as the compiler can parse through what you're doing, it treats it as valid.
Yeah, there was one quick thing I forgot to mention, so if we can back up a few steps,
because I have time.
There was one of these tricks.
You notice here, there's JavaScript and PHP, this trick doesn't work.
Does anybody know why?
First of all, did anybody see that first time round?
Nobody called me on it.
That's good.
The reason this is is because some languages, like JavaScript and PHP, treat all numbers
as floating point numbers no matter what.
And the floating point spec says that there is a negative zero and a positive zero; therefore,
the range of numbers is even on both sides.
This trick doesn't actually work in those languages.
So, quick digression there.
So as we head to our last slide, so what did this -- what did this do?
So it basically says 11 as it approaches one, this essentially prints, ten, nine, eight,
seven, six, five, four, three, two, one.
Time for the next presentation.
Thank you very much for listening.
[ Applause ] >>Matt Lowrie: Excellent.
Thank you, Brian.
Brian proving that there is absolutely no limit in talks you can create about the intricacies
and nuances of JavaScript.
>>Brian Vanpee: Yes.
If I had to say this presentation has a moral it's that even when you're writing test automation
or tests, you can fall into these traps as well, so be very aware of them.
>>Matt Lowrie: And I don't think we have any questions on the list, so if anybody has a
question in the room.
I guess my only question would be is why would anyone still use JavaScript?
>>Brian Vanpee: It's getting better, so I hear.
[ Laughter ] >>Matt Lowrie: Any -- Any questions?
I think you've all stumped us.
>>Brian Vanpee: Thank you very much for paying attention.
Appreciate it.
>>Matt Lowrie: Thanks.
[ Applause ]