Hvor finner jeg en bra oversikt over de siste meningsmålingene i Norge? Hva slags
informasjon kan man trekke ut av dem? Og hvordan pleier det å gå galt når en journalist
skriver om det, og hvor galt kan det bli?
Statistikk rundt meningsmålinger er en av de mest ironiske delfagene innen matematikk: de
interessante, opplagte konklusjonene fra råtallene pleier å være feil, men så snart de
begynner å bli sanne igjen er de ikke lenger så interessante.
Bonusmateriale: en kvalifisert gjetning for hvem som kommer til å vinne valget i Oslo.
Hvor finner jeg en bra oversikt over de siste meningsmålingene i Norge? Hva slags
informasjon kan man trekke ut av dem? Og hvordan pleier det å gå galt når en journalist
skriver om det, og hvor galt kan det bli?
Statistikk rundt meningsmålinger er en av de mest ironiske delfagene innen matematikk: de
interessante, opplagte konklusjonene fra råtallene pleier å være feil, men så snart de
begynner å bli sanne igjen er de ikke lenger så interessante.
Bonusmateriale: en kvalifisert gjetning for hvem som kommer til å vinne valget i Oslo.
Ever seen a drawing trying to explain the architecture or the functionality of an IT system, and you couldn't make any sense of it because it was drawn so badly? Do you feel that your drawings are OK, but could probably be improved substantially with a few tricks, but you don't really know what they would be?
I've made a lot of drawings over the years. I'm pretty sure not all of them were a success in terms of understandability. But at some point in time, I started reflecting on how my drawings look, and since then, I'm getting comments that apparently, my drawings look good.
In this session, I would like to share some of the reflections I make when I see somebody else's drawing, show you some obviously bad drawings and discuss what's wrong with them, and some of the tricks I use to create better drawings. The goal should be that when you leave this session, you've practiced a bit on how you can make your drawing look better, such that the reader or the viewer will understand it better.
How JSR 385 could have saved the Mars Climate OrbiterFilip Van Laenen
In 1999, NASA lost the $125 million Mars Climate Orbiter as it went into orbital insertion. Due to a mismatch between US customary and SI units of measurements in one of the APIs, the spacecraft came to close to the planet, passed through the upper atmosphere and disintegrated. Sadly, this hasn’t been the only instance where a mismatch between units of measurements had catastrophic consequences, but it’s certainly one of the most spectacular and expensive ones.
How could this happen? The bad news is: if you use primitive types to handle quantities in your code, due to that very same practice. At best, you’ve codified the unit in the name of the variable or the database field, e.g. calling it lengthInMetres. Otherwise, you’re only relying on convention, just like Lockheed Martin and NASA did.
Join this workshop to learn how JSR 385 can help you avoid $125 million mistakes, and discover the immeasurable world of dimensions, units and quantities.
Source code for the exercises during the workshop can be found at https://github.com/filipvanlaenen/booster2019.
How JSR-385 Could Have Saved the Mars Climate OrbiterFilip Van Laenen
In 1999, NASA lost the $125 million Mars Climate Orbiter as it went into orbital insertion. Due to a mismatch between US customary and SI units of measurements in one of the APIs, the spacecraft came to close to the planet, passed through the upper atmosphere and disintegrated. Sadly, this hasn’t been the only instance where a mismatch between units of measurements had catastrophic consequences, but it’s certainly one of the most spectacular and expensive ones.
How could this happen? The bad news is: if you use primitive types to handle quantities in your code, due to that very same practice. At best, you’ve codified the unit in the name of the variable or the database field, e.g. calling it lengthInMetres. Otherwise, you’re only relying on convention, just like Lockheed Martin and NASA did.
Join this talk to learn how JSR-385 can help you avoid $125 million mistakes, and discover the immeasurable world of dimensions, units and quantities.
Mutation testing is the true test for whether or not your source code does the right thing, and whether it's properly tested by your unit tests. But while we're on a killing spree against the mutants of our source code, let's reflect a bit on what these mutants really represent, and why we want to include the unit tests that kill them in our test suite.
What's the real point of boundary testing? Do we really need every statement in the source code? Have we tested all calculations? How do we know that we got all the access modifiers on our methods right? These are some of the questions that we would like to reflect on for a moment.
We'll start this talk with a short introduction to mutation testing, but only to set the stage. The core of this talk consists of a walk-through of Java code and unit tests, and a reflection on TDD and the quality of our unit tests. At the end of this talk you should be more suspicious about both your source code and your unit tests.
How Free Data Can Drive Some of the Monkey Business Out of Political Journali...Filip Van Laenen
Who will win the next election? Political journalists and scientist will be eager to tell you, but usually they're either telling you the obvious, or proposing their personal political preferences as a neutral expectation. How can we tell the difference?
There's a lot of free data (sadly not so much “open data”) out there about elections, going from general information about past and future elections, to detailed results per election constituency and polling data for upcoming results. Once you know where to look for the information, it's no so difficult to distill answers to the key questions around an upcoming question. Who will be the largest party in parliament? Who won't meet the threshold? Political journalists and scientists often give you the wrong answer, because they don't do the maths. This talk will tell you how you can do it right.
Ever seen a drawing trying to explain the architecture or the functionality of an IT system, and you couldn't make any sense of it because it was drawn so badly? Do you feel that your drawings are OK, but could probably be improved substantially with a few tricks, but you don't really know what they would be?
I've made a lot of drawings over the years. I'm pretty sure not all of them were a success in terms of understandability. But at some point in time, I started reflecting on how my drawings look, and since then, I'm getting comments that apparently, my drawings look good.
In this session, I would like to share some of the reflections I make when I see somebody else's drawing, show you some obviously bad drawings and discuss what's wrong with them, and some of the tricks I use to create better drawings. The goal should be that when you leave this session, you've practiced a bit on how you can make your drawing look better, such that the reader or the viewer will understand it better.
How JSR 385 could have saved the Mars Climate OrbiterFilip Van Laenen
In 1999, NASA lost the $125 million Mars Climate Orbiter as it went into orbital insertion. Due to a mismatch between US customary and SI units of measurements in one of the APIs, the spacecraft came to close to the planet, passed through the upper atmosphere and disintegrated. Sadly, this hasn’t been the only instance where a mismatch between units of measurements had catastrophic consequences, but it’s certainly one of the most spectacular and expensive ones.
How could this happen? The bad news is: if you use primitive types to handle quantities in your code, due to that very same practice. At best, you’ve codified the unit in the name of the variable or the database field, e.g. calling it lengthInMetres. Otherwise, you’re only relying on convention, just like Lockheed Martin and NASA did.
Join this workshop to learn how JSR 385 can help you avoid $125 million mistakes, and discover the immeasurable world of dimensions, units and quantities.
Source code for the exercises during the workshop can be found at https://github.com/filipvanlaenen/booster2019.
How JSR-385 Could Have Saved the Mars Climate OrbiterFilip Van Laenen
In 1999, NASA lost the $125 million Mars Climate Orbiter as it went into orbital insertion. Due to a mismatch between US customary and SI units of measurements in one of the APIs, the spacecraft came to close to the planet, passed through the upper atmosphere and disintegrated. Sadly, this hasn’t been the only instance where a mismatch between units of measurements had catastrophic consequences, but it’s certainly one of the most spectacular and expensive ones.
How could this happen? The bad news is: if you use primitive types to handle quantities in your code, due to that very same practice. At best, you’ve codified the unit in the name of the variable or the database field, e.g. calling it lengthInMetres. Otherwise, you’re only relying on convention, just like Lockheed Martin and NASA did.
Join this talk to learn how JSR-385 can help you avoid $125 million mistakes, and discover the immeasurable world of dimensions, units and quantities.
Mutation testing is the true test for whether or not your source code does the right thing, and whether it's properly tested by your unit tests. But while we're on a killing spree against the mutants of our source code, let's reflect a bit on what these mutants really represent, and why we want to include the unit tests that kill them in our test suite.
What's the real point of boundary testing? Do we really need every statement in the source code? Have we tested all calculations? How do we know that we got all the access modifiers on our methods right? These are some of the questions that we would like to reflect on for a moment.
We'll start this talk with a short introduction to mutation testing, but only to set the stage. The core of this talk consists of a walk-through of Java code and unit tests, and a reflection on TDD and the quality of our unit tests. At the end of this talk you should be more suspicious about both your source code and your unit tests.
How Free Data Can Drive Some of the Monkey Business Out of Political Journali...Filip Van Laenen
Who will win the next election? Political journalists and scientist will be eager to tell you, but usually they're either telling you the obvious, or proposing their personal political preferences as a neutral expectation. How can we tell the difference?
There's a lot of free data (sadly not so much “open data”) out there about elections, going from general information about past and future elections, to detailed results per election constituency and polling data for upcoming results. Once you know where to look for the information, it's no so difficult to distill answers to the key questions around an upcoming question. Who will be the largest party in parliament? Who won't meet the threshold? Political journalists and scientists often give you the wrong answer, because they don't do the maths. This talk will tell you how you can do it right.
1. MUTASJONSTESTING
LAG BUGS FOR Å FÅ BEDRE KODE
Filip van Laenen — Testdagen Odin 2015
1
https://www.flickr.com/photos/cskk/3759544397
2. Hvem er jeg?
2
●
18 år i IT-bransjen
– Utvikler (Java/Smalltalk/Ruby)
– Arkitekt/teknisk ansvarlig
– (Tester/QA)
●
Flere års erfaring med mutasjonstesting
http://www.slideshare.net/filipvanlaenen/
28. Ekvivalente mutasjoner
●
To forskjellige systemer som
alltid gir samme output for
samme input
●
Vanskelig å oppdage automatisk
●
Vanskelig å verifisere manuelt
28
https://www.flickr.com/photos/cq-biker/15606327367/
29. Ekvivalente mutasjoner
number max(a, b) {
if (a ≥ b) {
return a;
} else {
return b;
}
}
number max(a, b) {
if (a > b) {
return a;
} else {
return b;
}
}
29
https://www.flickr.com/photos/cq-biker/15606327367/
30. Ekvivalente mutasjoner
number max(a, b) {
if (a ≥ b) {
return a;
} else {
return b;
}
}
number max(a, b) {
if (a > b) {
return a;
} else {
return b;
}
}
30
https://www.flickr.com/photos/cq-biker/15606327367/
33. “
Hvorfor virker mutasjonstesting?
33
In practice, if the software
contains a fault, there will usually
be a set of mutants that can only
be killed by a test case that also
detects that fault.
Geist et. al., “Estimation and Enhancement of Real-time
Software Reliability through Mutation Analysis,” 1992
34. “
Hvorfor virker mutasjonstesting?
34
Complex faults are coupled to
simple faults in such a way that a
test data set that detects all
simple faults in a program will
detect most complex faults.
K. Wah, “Fault Coupling in Finite Bijective Functions,”
1995
35. “
Hvorfor virker mutasjonstesting?
35
Complex faults are coupled to
simple faults in such a way that a
test data set that detects all
simple faults in a program will
detect most complex faults.
K. Wah, “Fault Coupling in Finite Bijective Functions,”
1995
36. “
“
Virker mutasjonstesting?
36
Mutation testing is more powerful
than statement or branch
coverage.
Walsh, Ph.D. Thesis, State University of New York at
Binghampton, 1985
Mutation testing is superior to
data flow coverage criteria.
Frankl, Weiss, Hu, Journal of Systems and Software,
1997
39. Manglende testtilfeller
39
●
Tips til nye testtilfeller
– Avhengig av verktøyet
– Krever tilgang til rapportene
– Ikke alltid trivielt
http://www.javaadvent.com/2014/12/mutation-testing-in-java-with-pit-and.html
47. HVIS MUTASJONSTESTING ER SÅ BRA,
HVORFOR BLIR DET IKKE BRUKT?
47
https://www.flickr.com/photos/cskk/3759544397
48. Mutasjonstesting er gammelt nytt
●
Allerede beskrevet i 1971:
– R. Lipton, “Fault Diagnosis
of Computer Programs”
●
Videre forskning i løpet av 1970-
tallet:
– R. Lipton et. al., “Hints on
Test Data Selection: Help
for the Practicing
Programmer,” 1978
48
49. Historiske hindringer
●
Mangel på enhetstestingverktøy
●
Mangel på enhetstestingpraksis
– TDD
●
Ineffektive implementasjoner
– Lange prosesseringstider
●
Integrasjon med utviklingsverktøy
49
66. HVORDAN KOMME I GANG?
66
https://www.flickr.com/photos/cskk/3759544397
67. Hvordan komme i gang
●
Velg riktig verktøy
●
Om mulig, bruk fra dag 1
●
Avgrens i begynnelsen
– Kritisk kode
– Relevante mutatorer
●
Lær å bruke verktøyet
– Tro på hva det sier
– Eller bevis at det tar feil
67
69. Er mutasjonstesting nyttig?
69
●
Enkle prinsipper
●
Veldig kraftig verktøy
●
Utfordringer rundt ytelse
●
Verktøyene blir bedre og bedre
Ja, forutsatt at enhetstesting er på plass
70. Er mutasjonstesting nyttig?
70
●
Enkle prinsipper
●
Veldig kraftig verktøy
●
Utfordringer rundt ytelse
●
Verktøyene blir bedre og bedre
Ja, forutsatt at enhetstesting er på plass
71. Er mutasjonstesting nyttig?
71
●
Enkle prinsipper
●
Veldig kraftig verktøy
●
Utfordringer rundt ytelse
●
Verktøyene blir bedre og bedre
Ja, forutsatt at enhetstesting er på plass
72. Takk for din oppmerksomhet!
72
Contact information:
@filipvanlaenen
fvl@computas.com / f.a.vanlaenen@ieee.org
https://no.linkedin.com/in/filipvanlaenen
https://leanpub.com/mutationtesting http://www.slideshare.net/filipvanlaenen/