Player is loading...
Testing in the postapocalyptic future
Daniel Westheide, INNOQ
Wednesday, June 12, 2019 · 2:32 p.m. · 43m 10s
One popular way of testing in the Scala community is property-based testing - by generating random, often unexpected test data, it can uncover shortcomings in our implementations. In this talk, you will learn about a completely different approach, _mutation testing_: By mutating your code, it tests your tests and tells you a lot more about the quality of your tests than metrics like code coverage. We're going to cover what mutation testing us, how you can use it in your Scala projects, how it compares to property-based testing, and the challenges of implementing this approach in Scala.
Embed
Transcriptions
Note: this content has been automatically generated.
00:00:00
it's um it's two thirteen so i think it's time to begin
00:00:06
yeah
00:00:07
so there's not actually part of my slide because some people asking
00:00:13
he looks slightly post apocalyptic
00:00:20
so hello everyone i'm i'm really excited to be back had studies for the third time
00:00:27
and welcome to my talk on testing in the post apocalyptic future to it so
00:00:38
skylights pretty powerful type systems but this talk is
00:00:43
for those people understand that this is not enough
00:00:47
and that if we want to deliver high quality software that we
00:00:52
must also spent time in creating a strong tests read it um
00:01:00
in particular you learn about their techniques called mutation testing
00:01:07
and also how it relates to other techniques in the context of testing
00:01:14
so the question is how do we actually recognise what a strong tests read it
00:01:22
so there are some people who think that code coverage of test coverage is good metric for
00:01:28
the quality of the tests read so the higher the coverage um the stronger the test suite
00:01:36
and some of these people even establish quality gates in there the pipelines so if so
00:01:44
coverage um it's below a certain threshold and build will just fail
00:01:52
now consider this function which simply checks whether
00:01:56
given integer value is non negative or not
00:02:04
so if if we want to test although
00:02:08
importance scenarios that we can think of we need to create at least three different test cases
00:02:14
and this is how we can do it in this example i'm using a mini test
00:02:21
and if we do this then we get the bronx coverage of one hundred percent so run coverage is the
00:02:28
ratio of all the branches in the code on the test that actually gets executed when you wanna test three
00:02:35
and it's colour prancing usually happens through if expressions or haven't matching expressions
00:02:42
another thing is the following tested also gives us one hundred
00:02:47
percent branch coverage even though we reduced to pretty important cases
00:02:56
and we can go even further because we don't actually need to put an end to any assertions into a test
00:03:03
so this test of course it can never fail
00:03:07
because it just prince something to the console and doesn't have any assertions
00:03:15
so code coverage doesn't care at all about your assertions
00:03:19
all that matters is if you code has been executed us
00:03:25
so let's get back to this question i think it's the fair to say
00:03:29
but if we see a very low code coverage we know that we don't have strong tests read
00:03:35
but having a high code coverage doesn't really
00:03:39
so it was an indicator of strong test suite
00:03:46
so here are a few qualities of what a strong test we might
00:03:53
might be so tests actually have assertions that's a great thing
00:03:59
um and of course we should also not just test the happy part and in fact we should cover all the corner cases
00:04:07
and father that even corner cases that we haven't thought of
00:04:13
so i think it's important that we stop
00:04:16
obsessing moves um questionable metrics like oh coverage
00:04:22
and it's that we should focus on to that actually help us improve the quality of
00:04:26
our test three so what are the state of the art tools that we have available
00:04:34
well one such to that many of you might know is property based testing
00:04:39
actually it has gained a lot of 'em traction even beyond the
00:04:43
functional programming communities nowadays so i've seen it used in some java projects
00:04:49
um and compared to traditional unit testing this is a pretty different way of writing a test
00:04:57
of course property best testing is is not the main topic of the stock but i still want to give a quick introduction
00:05:02
to how it works so that you can get an idea of what mutation testing can do for you in comparison to other techniques
00:05:12
okay so we have another function non negative ratio
00:05:17
which actually uses the non negative function we had seen before so this gives will a given a list of integers
00:05:24
which ones the ratio of those images um and that list
00:05:29
that on on negative is is actually a pretty simple function
00:05:38
now in traditional unit testing them we need to come up with concrete example to describe the desired behaviour
00:05:45
how to function on the test so here we have three examples that we came up with
00:05:52
more or less arbitrary
00:05:57
and this is what it would look like with property based testing i've only given that a single property here
00:06:05
uh which fits on one slide but basically in contrast to the traditional unit
00:06:11
testing we describe general properties of the code on the test that must hold true
00:06:17
sometimes is also called generative testing because the test library
00:06:22
actually creates tests for you by creating different input values randomly
00:06:28
and by doing that it usually covers all the different corner cases as well for this is
00:06:34
uh we interesting property of property based testing
00:06:40
so in this example property what to say is um if i have a random list of into just um
00:06:49
the non negative rate non negative ratio of that plus the non negative ratio
00:06:54
of inverting this list somehow with the function below should always be one hundred
00:07:03
i think one of the biggest strength of property based testing is
00:07:06
that it had to time cover gaps in the code in the test
00:07:11
and this is exactly what happens here if we execute this properties test that you saw before
00:07:17
because we get and arithmetic exceptions uh we try to divide by zero because
00:07:23
somehow we haven't thought of the case of passing in an empty list and
00:07:29
the property based testing tool that we use just happen to generate a test case for us doing that
00:07:37
so what could we do in this example where we could fix issue either by narrowing down the input type
00:07:44
to something like non empty list or by widening the output type to an option of pick doesn't
00:07:51
but we won't go into that now um because we actually want to talk about vacations that's ah
00:08:00
so property based testing is great because it forces us to
00:08:03
think about the general properties of the functions we want to test
00:08:08
and because as we just saw it helps us to uncover some unknown
00:08:12
box or gaps in the implementation of the code that we want to test
00:08:18
but it isn't a guarantee for strong test suite
00:08:22
so in this talk i want to introduce an additional technique what tool that we have at our disposal
00:08:29
to um guarantee that we have a strong test read or at least to help with that and that's mutation testing
00:08:38
so what is mutation testing well unlike property based testing
00:08:43
that it's not yet another way of writing your text so
00:08:48
it does not replace traditional unit testing or property based testing you can use it with either of these
00:08:54
you don't need to change anything about how you write your tests rather it's a tool to test your test
00:09:02
and by doing that it can give you a lot of valuable insights into where few weeks what's in your test really um
00:09:10
and where you could improve it
00:09:12
it's actually it's goals are more similar to that of code coverage
00:09:18
but um in my opinion it does a far better job that achieving these goals
00:09:26
so how does it work um
00:09:30
as already mentioned code coverage only measures measures whether your code has been
00:09:34
executed on not iteration testing willie tests whether your assertions i any good
00:09:41
and it does that by making changes to the code on the test
00:09:46
and then after making these changes it once you test suite against the modified code
00:09:53
and then we'll see if your test actually care about whether the code on the test has been changed or not
00:10:02
okay now there are various wage that we can could think of in which we could change the code and the test
00:10:09
and here you can see just a few examples for instance we could
00:10:14
look for occurrences of the greater than operator and replace them with weight equals
00:10:20
or with lower than but these are really just a few examples and there
00:10:25
are more ways of mutating the code which will we will see a bit later
00:10:32
but the point is um so each strategy like this for
00:10:36
um changing the code mutating the code is called a mutation
00:10:41
and what we want as mutations are changes that are
00:10:46
very likely to um change the behaviour of your code
00:10:51
is is completely different from what you want when you do re factoring of function because then you want it to be exactly the same behaviour
00:11:03
so when we apply a mutation to some specific piece
00:11:07
of code um what we create is called a mutant
00:11:13
so for each mutation three b. look in a source file and
00:11:18
um find candidates
00:11:21
pieces of code that we want to change um so each occurrence of
00:11:27
the greater than operator in this example um could be replaced
00:11:32
by a greater equals and would be it on mute and uh
00:11:38
and also each occurrence could be replaced by a lower than for example
00:11:44
but the important thing is that we will create many different mutants
00:11:48
in our project and all of them have to be tested in isolation
00:11:52
so we re not mutate to operators here together and say this is one mutant but only one of them
00:12:03
so i said after changing the court we need to run the test read and see what happens so
00:12:11
in this example have a function on the test with three mutants and i have any
00:12:18
tess street is is that is fairly extensive and what happens
00:12:23
uh is that each of these mutants leads to any at least one actually to failing test and
00:12:30
it's read so this means the test suite is failing for each of these mutants and that's good
00:12:37
because it means that assertions i actually testing the behaviour of the
00:12:40
code um a good test should fail if you tamper with the code
00:12:46
and i failed test means that the respective mutant has been detected
00:12:52
and here is an example where we have a less extensive tests we again we have three mutants
00:12:59
and what happens here is when we won the tests read for the first newton is that the test still succeeds
00:13:07
and this is bad
00:13:09
so we have tampered with the tested code but it doesn't seem to have any effect on our tests we
00:13:16
as successful test means that the respective mutant has not been detected
00:13:22
and of course each undetected mutant can tell us a lot about a problem in our test three
00:13:31
so do i need that's that's a good question so maybe your things you don't need this tool
00:13:36
because you are very experienced software developer so you're
00:13:40
totally know how to create a high quality test suite
00:13:44
i maybe even use property based testing every just all that you can cover all the corner cases with it
00:13:50
so of course you have a great test suite because use property based testing
00:13:55
and you don't need it to like this
00:13:59
well i think uh that's not true i swear experience um
00:14:05
well i think experience doesn't prevent you from being sloppy on the pressure for if you're in a hurry
00:14:12
and you can all always make mistakes so it's definitely go
00:14:15
to have uh to to check against that and property based testing
00:14:21
and mutation testing i think they approach a common goal
00:14:26
of high quality software but coming from two different angles
00:14:30
so property based testing generates test so with unexpected input data
00:14:35
as we just saw so it can help you to reveal
00:14:39
that your code on the test doesn't cover certain common cases that it has kept
00:14:45
mutation testing on the other hand uh can reveal that your code on the test um has some
00:14:51
logic that is not fully covered but test so this helps to improve the quality of your tests
00:14:57
so these are the two angles for improving the quality of your software
00:15:03
so they uh actually orthogonal to each other and i think that oh really good match
00:15:09
and just like occasion testing property based testing is just
00:15:12
a tool so of course you can write that properties that
00:15:16
don't assert anything meaningful and then mutation testing can definitely help you to find those
00:15:23
weak spots in your test suite
00:15:27
so now we are to point value interrupt me and say okay then yeah you have
00:15:31
convinced me so you need this notation testing thing for your project can you buy it anywhere
00:15:39
where there are a few languages that have a really mature a mutation testing tools available
00:15:47
for example in the family of get yeah in ruby that's
00:15:51
mutants in sky we are a bit late to the parking
00:15:56
which is of course one much talk is called testing in the post apocalyptic future uh
00:16:03
so this was more than two years ago i treated that scott my that would actually be a great tool for
00:16:10
creating a star levitation testing to see i'm not i'm going to show you why that is the case
00:16:19
because i think if you see how such a tool can be implemented it helps
00:16:22
a lot together a deeper understanding all from high mutation testing works and what it does
00:16:30
so we'll see that it's possible to create a proof of concept s.
00:16:33
p. t. plugin for mutation testing and lesson two hundred lines of code
00:16:40
and i'm calling this plug in the london with chandra which is
00:16:44
actually as spell from a german fantasy role playing game from the eighties
00:16:49
and of course that's a transformation spare and the spells in the eighties always
00:16:54
had these silly rhymes thoughts cause that i'm i'm what time does iodine and
00:17:00
um i was only going to the most interesting aspect of implementing this um of desk
00:17:05
quite a bit of s. p. t. stuff that is not really relevant to the stocks
00:17:13
so the main ingredients on s. p. t. and scar metals
00:17:18
and basically the whole process consist of four steps
00:17:22
first we need to find all scholars all files on the test
00:17:25
then for each of them we need to yield mutants for applicable mutations
00:17:31
for each mutant we need to run the whole test we'd and then finally want an allies unlock the results
00:17:39
okay
00:17:40
so this is what it looks like ends calico i think actually
00:17:47
if we remember the previous slide it actually translates quite well to these four steps
00:17:55
so we what we get here is an incantation would give us some
00:17:59
information about the mutation testing one for example the
00:18:03
directory of of the main sources and stuff like that
00:18:08
i'm getting the files is actually not very interesting interesting parts of finding the mutants applying the
00:18:16
have that getting the mutations and applying the mutants from
00:18:20
those and then running an experiment for each of the mutants
00:18:25
so we we will look into these now
00:18:30
uh to summon the mutants as i said we rely heavily on scott matter
00:18:35
and if you don't know this library um it's a great like before reading transforming generating it's got a code
00:18:44
and it has this abstract syntax tree representation of your code tree
00:18:50
uh which allows you to patton mention it you can compare to trees for
00:18:54
equality and you can also traverse the tree and this is exactly what we need
00:19:02
there are a few methods for traversing the tree and the one we uses caught collect
00:19:08
it expects a partial function from each really to somehow battery type t.
00:19:13
and returns a list of t. so what this means you need to pass in the partial function um
00:19:20
and whenever that function is defined for each of these notes um the function is applied and the values collected
00:19:28
so it actually is a bit similar to collect method you know firms colour collections
00:19:37
okay so we need a way to define some mutations
00:19:42
and we can think of a mutation as a recipe for finding places in a
00:19:46
source file that we want to change and then also for how to apply these changes
00:19:52
so that is why i have to find a tight areas for mutation from as
00:19:57
a function from source file to a partial function from tree to list of mutant
00:20:03
list of mutant because for each thing we find we want might want to apply different kinds of changes
00:20:12
so this possible function actually is compatible with the collective method we already saw we could pass that in in
00:20:19
this case you can see this is the change from greater you could still high the greater than or equal to
00:20:26
and you can see that we make heavy use of the pattern matching functionality that we can use on the tree
00:20:35
so we look for in in fix application of a great equals operator
00:20:41
and if we find one we could reach a list of mutants very
00:20:45
just create a copy of history and change the name of the operator
00:20:52
so we have to you don't see one with greater than on it equals
00:20:58
every meeting gets a random u. u. i. d. that's just because we need to identify
00:21:02
the mutant later and you want to store the change source code in the unique temporary directory
00:21:11
so of course we have more than one mutation and together all of the
00:21:15
mutations that we want to support constitute the spell book as a list of notation
00:21:24
and now
00:21:26
we need a way to collect the mutants from the source file so in the mutations object i have to find
00:21:32
the method in which retrieves a would expect the source
00:21:36
file returns a partial function from tree to list of mutant
00:21:41
so this is possible function has the same signature as the one which aren't
00:21:46
by any mutation but what it does is it goes through a spell book folded
00:21:52
uh chains all the possible function with or else
00:21:57
and then just if you pass this partial function to collect for source file
00:22:04
and flatten the result and we get a list of all the
00:22:07
mutants that uh we support or that we could find forgiven source fine
00:22:18
so when we won the tests really against the mutant we need to return whether or the respective
00:22:24
mutant was detected on not for this we need some i correct data type which i call without
00:22:30
and in my case it only has three variations detected undetected or error
00:22:39
so running an experiment we do that for each signal mutant and here we need to do some s. p. t. stuff so
00:22:50
we have already incantation was some basic information and we have the individual mute and and for that
00:22:56
mutant we want to create a source directory which first contains a complete copy of a normal main sources
00:23:05
and uh what it then what we then do in creates austere it's not showing is that we also stole the um
00:23:14
the mutated so them scallop method three back to a scholar source code
00:23:21
and then we need to create some s. p. t. settings so that we can point s. p. t. two
00:23:28
this a mutant specific um source directory and target directory
00:23:35
and then we have to run this test task and map the
00:23:39
result of funding the s. p. t. task to either an error
00:23:44
or to an undetected mutant or detective would so this is how we run the experiment
00:23:54
yeah let's see an example of using that's so yeah we have a function non negative which we already know and the
00:24:02
tests we that is not very good and when we one and one and s. p. t. cell on the mountain or
00:24:08
we see first the number of total mutants the number
00:24:12
of detected mutants and for each undetected mutant we also see
00:24:17
rich mute and it was so this is a mutation that was applied and this is the position in the source code
00:24:25
and this again is something that we can only do because colour matter tries
00:24:29
to a preserve as much information as possible so we get the position of uh
00:24:36
of the code that we change
00:24:41
okay but this is a nice proof of concept and maybe
00:24:46
nice for educational purposes but it has a number of weaknesses
00:24:51
and the first one is of course a very limited number of mutations that i support
00:24:56
another one is that this console reporting that you saw it's it's very basic i mean it
00:25:02
in general it it works but i'm sure it can be done nice uh
00:25:08
and the performance i didn't test it i'm only use the small example
00:25:12
well i'm convinced that it would be horrible because i know about the
00:25:17
optimisation that can be done and i will introduce them a bit later i
00:25:26
another good thing is that there are already a few people out there who started working
00:25:30
on a proper mutation testing tool false colour and not just a proof of concept so all
00:25:36
remember this tree from more than two years ago and then
00:25:40
one and a half years later who was actually sitting over there
00:25:44
confirmed my suspicion that's colour but it's a really good too for this
00:25:49
so who and his team they created striker for us
00:25:54
and in fact i took some inspiration from striker for us and simplify
00:25:58
things for that and number ten on for educational part of a soul
00:26:07
strike a for s. has its name because it is caught
00:26:10
up a lot of annotation testing tool called striker for javascript
00:26:16
and it's uh not only development stage and there are some quirks
00:26:20
but it's available today you can use it you can try it
00:26:24
so let's see what we can do for you
00:26:30
so my proof of concept as asset only has a limited number of mutations
00:26:35
and strike a for a support slot mall mutations for example it can replace a literal
00:26:42
uh it can replace a condition in and if expression with the lives were boolean value
00:26:50
equality operators other things that i partially supported a microsoft concept
00:26:55
then we have the logical operators and something that's very interesting and
00:27:00
various colours specific it has method expression replacements and most of them are
00:27:08
targeting the star collection library so this is just an example if you have
00:27:13
a call to the take method it can get replaced by a drop method
00:27:17
but there's also stuff like replacing and exists matter with the fall and stuff like that
00:27:23
so this is really nice
00:27:28
to the console reporting in my proof of concept also was a weakness i said um because
00:27:36
mutation testing is a tool that should help us gain insights of course this is a really
00:27:41
um that thing and strike a four s. does a lot better it
00:27:47
has it's really shiny h. t. m. l. report that generates for you
00:27:52
so what you can see here is first you can um decide if
00:27:57
you want to see all mutants or just the killed once all survived ones
00:28:02
so this is the terminology that striker uses for detected or undetected
00:28:08
and then for each of them you can also see what actually happened so i have one that was killed where and
00:28:16
a string consisting of a space was replaced by an empty string but i also have to here in this example that
00:28:23
oh we're not detected where a boolean value was was changing false and true for example
00:28:30
or a string was replaced by an empty string separately i
00:28:34
have some gaps in my tests week uh in this application
00:28:40
and this report really helps to visualise where the problems are
00:28:47
performance as i said i'm not proof of concept will likely
00:28:50
i have a very bad performance and the problem really is that
00:28:54
of course that's colour compiler is not the fastest one in the world
00:28:59
and this is a big problem for mutation testing because we create a lattice
00:29:05
different mutants and each of them must be tested in isolation
00:29:09
so we need to do the steps compiler main sources um
00:29:14
test everything um we need to do that as often as we have mutants and i can take a lot of time
00:29:24
so some mutation testing tools on the j. v. m. like it they kind of solve this problem by not
00:29:30
changing the source code but the j. v. m. byte code is is not a really good solution for schuyler
00:29:36
um because we have binary incompatibility between may just televisions um so it'll probably
00:29:43
be a nightmare to maintain this kind of stuff and it's very error prone
00:29:51
so what strike us or striker for as a at least
00:29:55
a it uses the technical mutation switching uh so the coat
00:30:02
um that it generates them introduces yeah pattern matching expression
00:30:08
i'm using environment variable so we confuse multiple mutants into one
00:30:13
compilation run so this is a a really good speed up
00:30:17
and at one time we pass in some different values for
00:30:22
this environment variable rebel and this decides which branch actually gets executed
00:30:29
i
00:30:32
so how can you strike up but it is available as a plugin for a speech your maiden i'm focusing as p. t. here
00:30:40
and i think it was today that were released a new version or maybe yesterday i can't remember
00:30:47
yesterday evening so i had to update my slides today so the current version is you
00:30:52
would at five to zero you can just add it as an s. p. g. plugin
00:30:56
and then you have to come on striker which you can call like any other task
00:31:02
um configuration doesn't um happen through s. p.
00:31:05
t. settings but using a whole come configuration file
00:31:10
which allows you to for example disable certain mutations or
00:31:13
to narrow down which source files should be considered for mutation
00:31:19
you can also set a threshold for the detection weight of mutants um or change the
00:31:24
base directory which i will talk a little bit about later why that might be useful
00:31:31
so how can you use it
00:31:34
well how should you use it
00:31:37
well i would not recommend to have a mutation testing step in your c. i. pipeline
00:31:42
um at least not if you want to do continues delivery or deployment because it just takes too long
00:31:48
so for this very tiny um spock application had we just saw the h. m. m. report for it just takes
00:31:55
one or two minutes but for very big applications it it can take several hours so i would recommend too
00:32:03
run this on the schedule paces and not for each commit tool some bronze for example
00:32:08
once or twice a day and to not use it as a quality gate but just
00:32:15
to get a report and get some insights and then you need to
00:32:18
plan sometime regulate to go through the report and improve your test suite
00:32:26
and of course um if all you mutants actually were detected or many of them
00:32:32
it's still not guarantee for strong tests read but at
00:32:35
least you get a lot more confidence than with code coverage
00:32:42
so there are a few interesting challenges that every mutation testing to has to deal with
00:32:47
and some scar specific ones um i want to talk about both of them little but
00:32:53
and also about some quirk some limitations that strike for is still has has the
00:32:58
young project that it's that is but i'm also confident that they will be solved soon
00:33:06
so one issue is um that
00:33:09
hasn't been solved instructor for as yet is that some mutants might actually not comply
00:33:16
for example if you have a filter method uh there's no guarantee that you
00:33:21
have a filter not method just happens to be the case for scarlet collections and
00:33:28
in santa the problem is actually worth that because even for basic operators like greater than um
00:33:36
you can't be sure whether they also have a way to
00:33:39
equals the respective types because it's just methods and and um java
00:33:45
for example of course these are operated a back into the language
00:33:49
and the only work for primitive types still they will always work
00:33:55
but if i wipe my own class with a greater than method no one
00:34:00
can now if if this mutation to wait you control work because we don't
00:34:05
have any type information says calamitous syntax trees exactly that it's just the syntax tree
00:34:11
um and currently if we have such a compiler and strike up for us and the whole mutation test one will fail it
00:34:23
a few other issues um
00:34:27
any mutation testing tool has the challenge that it can cause infinite loops
00:34:32
the chance of that is a bit reduced and strike a for us because
00:34:37
for a while loop it will never replace expression with true of course but still it can happen otherwise
00:34:44
uh that you cause an infinite loop and currently there's no
00:34:47
control over the test process so the mutation run cannot be stopped
00:34:53
teletext on another issue is that multi module projects are currently not we supported
00:35:01
but for that you can use a base directory kentucky in the
00:35:05
setting so you can set it to the directory of some sub project
00:35:10
and um and then this work
00:35:15
and finally performance we saw that the compile performance was improved but
00:35:22
um there's still some possible improvements regarding actually running the tests
00:35:27
because currently the complete test read um this run for each mutant
00:35:34
there are some ideas and plans that who told me about
00:35:38
uh run is uh to keep the test process alive currently my understanding is
00:35:44
that for every test suite one um and you j. b. m. as four
00:35:50
um another thing is that you could ignore mutants that don't have
00:35:55
any test coverage because why would you want the whole test beautiful
00:35:59
code doesn't have any test coverage at all and it and another issue with this is that for each mutants um
00:36:09
you could only run the test that actually hitting the respective code um that is changed by the mutant
00:36:20
yeah and uh the topic of compile errors cost but mutants them
00:36:27
there is um an idea for introducing a rollback mechanism
00:36:33
and some idea of exploring whether type analysis using semantic t. t. v. might have
00:36:43
of course with us colour three
00:36:46
uh the question is whether maybe tasty can actually help with that
00:36:51
and at the same time tasty might actually improve the performance because you need to don't need to compile from source anymore
00:37:01
okay so regardless of whether you do traditional unit testing all property based testing i think um
00:37:07
iteration testing is a valuable to to add to your and too but
00:37:13
so i i invited to look at it and consider
00:37:15
it um and especially to give striker for us to try
00:37:22
um i'm sure who and esteem would be happy about any feedback and
00:37:26
probably also about additional contributors are um and they also have stickers
00:37:31
actually if you want to stand up so people can recognise you
00:37:38
oh okay yeah so
00:37:44
um that's it basically about mutation testing i have something for
00:37:49
you uh the first one is the this a proof of concept
00:37:54
the second one is striker for us
00:37:57
that's actually the one you should look at it and the block pause about
00:38:01
mutation switching the technique that i talked about four intrude uh reducing compile times
00:38:08
and if you're interested in what's colour matter can help you building maybe
00:38:13
uh other ideas for the tools and of course that's calamity website is
00:38:18
definitely worth a look okay thank you and i'm available
00:38:31
um hi things let's soak 'em was
00:38:35
bees gas saturday eighty imitation was there
00:38:39
you can have the mansion and they said yes he did not function yeah
00:38:47
bees says something crazy like this guy's actually be high any scene dang it you have to
00:38:53
uh neckties had exactly the same signal chair last one name a c. e. and a. t. shirt
00:39:01
well i think when you only have access to the syntax trees calamity and then you don't really have
00:39:08
a reflection available because you you only know that there
00:39:11
is um some in in vocational from method and it happens
00:39:17
to have a label as a string which is called filled out and make sense so you don't actually know what other methods are available
00:39:27
oh this is rest semantic to be maybe might help because there you can actually look up the methods that are available for some type
00:39:35
okay um i have a question about mutation testing the rule thing um you mentioned it
00:39:40
to me to use oh it looks which is one kind of the sector they could introduce
00:39:45
well what about cases where you know let's say you constructing a
00:39:50
partially worthwhile to in the meeting just makes little feels wrong with huh
00:39:54
then you may be deleted file that this also those you're used public would you recommend
00:39:58
against the playing mediation testing to coded up with possible the strategies to like a weed
00:40:06
from what appeared
00:40:10
uh that's an interesting question well i think it's a good technique for
00:40:16
um testing the unit tests and if we are functional
00:40:20
problem within the unit has probably only test your code right
00:40:24
so i think for integration testing it's uh it's maybe not the best to all also because of the speed
00:40:31
of course i'm living there are so many mutant that you want to test and it has to be quite fast
00:40:39
and as for the infinite loops by the way um if you introduce an infinite loop
00:40:45
by creating a mutant and actually the mutant should
00:40:49
count as detective because you have changed behaviour or so
00:40:57
once try cover has has control over that has process then
00:41:02
if there is an infinite loop it should probably just aborted after sometime encountered as a detected mutant
00:41:10
any other questions
00:41:15
oh that's the question here in the first well
00:41:19
one moment some microphones come as you mentioned you beat the system yes it does
00:41:26
which one was chew division this to you through the uh the
00:41:32
with was the was the the u. p. two what does it do
00:41:36
so what you're looking for is compared with the the the the the um
00:41:44
so the question i am not sure everyone heard it was it was
00:41:47
not very loud um was whether there's a comparison between the features and it
00:41:52
for job or and strike up for us but i don't think the documentation currently has um
00:41:58
any um comparison like that but of course because it is such
00:42:04
a mature project you can definitely ah it's i'm expected to have um
00:42:13
probably a few more um
00:42:16
mutants well i'm human patients um on the other hand um i think striker has a lot of colour specific
00:42:23
um mutations that with this colour collections but they definitely have um
00:42:31
more control over the test process they have already optimised the performance
00:42:35
quite a bit and they also run the tests in parallel or the mutant
00:42:40
so yeah but it's not a tool that you you could easily
00:42:44
used to test its colour code because it changes the byte code
00:42:48
and the generated by people from scotland as we know we can change between versions
Conference Program
A Tour of Scala 3
Martin Odersky, Professor EPFL, Co-founder Lightbend
June 11, 2019 · 5:15 p.m.
8337 views
A story of unification: from Apache Spark to MLflow
Reynold Xin, Databricks
June 12, 2019 · 9:15 a.m.
1267 views
In Types We Trust
Bill Venners, Artima, Inc
June 12, 2019 · 10:15 a.m.
1569 views
Creating Native iOS and Android Apps in Scala without tears
Zahari Dichev, Bullet.io
June 12, 2019 · 10:16 a.m.
2232 views
Techniques for Teaching Scala
Noel Welsh, Inner Product and Underscore
June 12, 2019 · 10:17 a.m.
1296 views
Future-proofing Scala: the TASTY intermediate representation
Guillaume Martres, student at EPFL
June 12, 2019 · 10:18 a.m.
1157 views
Metals: rich code editing for Scala in VS Code, Vim, Emacs and beyond
Ólafur Páll Geirsson, Scala Center
June 12, 2019 · 11:15 a.m.
4695 views
Akka Streams to the Extreme
Heiko Seeberger, independent consultant
June 12, 2019 · 11:16 a.m.
1552 views
Scala First: Lessons from 3 student generations
Bjorn Regnell, Lund Univ., Sweden.
June 12, 2019 · 11:17 a.m.
577 views
Cellular Automata: How to become an artist with a few lines
Maciej Gorywoda, Wire, Berlin
June 12, 2019 · 11:18 a.m.
386 views
Why Netflix ❤'s Scala for Machine Learning
Jeremy Smith & Aish, Netflix
June 12, 2019 · 12:15 p.m.
5026 views
Massively Parallel Distributed Scala Compilation... And You!
Stu Hood, Twitter
June 12, 2019 · 12:16 p.m.
958 views
Polymorphism in Scala
Petra Bierleutgeb
June 12, 2019 · 12:17 p.m.
1113 views
sbt core concepts
Eugene Yokota, Scala Team at Lightbend
June 12, 2019 · 12:18 p.m.
1655 views
Double your performance: Scala's missing optimizing compiler
Li Haoyi, author Ammonite, Mill, FastParse, uPickle, and many more.
June 12, 2019 · 2:30 p.m.
837 views
Making Our Future Better
Viktor Klang, Lightbend
June 12, 2019 · 2:31 p.m.
1682 views
Testing in the postapocalyptic future
Daniel Westheide, INNOQ
June 12, 2019 · 2:32 p.m.
498 views
Context Buddy: the tool that knows your code better than you
Krzysztof Romanowski, sphere.it conference
June 12, 2019 · 2:33 p.m.
394 views
The Shape(less) of Type Class Derivation in Scala 3
Miles Sabin, Underscore Consulting
June 12, 2019 · 3:30 p.m.
2321 views
Refactor all the things!
Daniela Sfregola, organizer of the London Scala User Group meetup
June 12, 2019 · 3:31 p.m.
514 views
Integrating Developer Experiences - Build Server Protocol
Justin Kaeser, IntelliJ Scala
June 12, 2019 · 3:32 p.m.
551 views
Managing an Akka Cluster on Kubernetes
Markus Jura, MOIA
June 12, 2019 · 3:33 p.m.
735 views
Serverless Scala - Functions as SuperDuperMicroServices
Josh Suereth, Donna Malayeri & James Ward, Author of Scala In Depth; Google ; Google
June 12, 2019 · 4:45 p.m.
936 views
How are we going to migrate to Scala 3.0, aka Dotty?
Lukas Rytz, Lightbend
June 12, 2019 · 4:46 p.m.
709 views
Concurrent programming in 2019: Akka, Monix or ZIO?
Adam Warski, co-founders of SoftwareMill
June 12, 2019 · 4:47 p.m.
1974 views
ScalaJS and Typescript: an unlikely romance
Jeremy Hughes, Lightbend
June 12, 2019 · 4:48 p.m.
1377 views
Pure Functional Database Programming‚ without JDBC
Rob Norris
June 12, 2019 · 5:45 p.m.
6374 views
Why you need to be reviewing open source code
Gris Cuevas Zambrano & Holden Karau, Google Cloud;
June 12, 2019 · 5:46 p.m.
484 views
Develop seamless web services with Mu
Oli Makhasoeva, 47 Degrees
June 12, 2019 · 5:47 p.m.
785 views
Implementing the Scala 2.13 collections
Stefan Zeiger, Lightbend
June 12, 2019 · 5:48 p.m.
811 views
Introduction to day 2
June 13, 2019 · 9:10 a.m.
250 views
Sustaining open source digital infrastructure
Bogdan Vasilescu, Assistant Professor at Carnegie Mellon University's School of Computer Science, USA
June 13, 2019 · 9:16 a.m.
374 views
Building a Better Scala Community
Kelley Robinson, Developer Evangelist at Twilio
June 13, 2019 · 10:15 a.m.
245 views
Run Scala Faster with GraalVM on any Platform
Vojin Jovanovic, Oracle
June 13, 2019 · 10:16 a.m.
1340 views
ScalaClean - full program static analysis at scale
Rory Graves
June 13, 2019 · 10:17 a.m.
463 views
Flare & Lantern: Accelerators for Spark and Deep Learning
Tiark Rompf, Assistant Professor at Purdue University
June 13, 2019 · 10:18 a.m.
380 views
Metaprogramming in Dotty
Nicolas Stucki, Ph.D. student at LAMP
June 13, 2019 · 11:15 a.m.
1250 views
Fast, Simple Concurrency with Scala Native
Richard Whaling, data engineer based in Chicago
June 13, 2019 · 11:16 a.m.
624 views
Pick your number type with Spire
Denis Rosset, postdoctoral researcher at Perimeter Institute
June 13, 2019 · 11:17 a.m.
245 views
Scala.js and WebAssembly, a tale of the dangers of the sea
Sébastien Doeraene, Executive director of the Scala Center
June 13, 2019 · 11:18 a.m.
661 views
Performance tuning Twitter services with Graal and ML
Chris Thalinger, Twitter
June 13, 2019 · 12:15 p.m.
2003 views
Supporting the Scala Ecosystem: Stories from the Line
Justin Pihony, Lightbend
June 13, 2019 · 12:16 p.m.
163 views
Compiling to preserve our privacy
Manohar Jonnalagedda and Jakob Odersky, Inpher
June 13, 2019 · 12:17 p.m.
301 views
Building Scala with Bazel
Natan Silnitsky, wix.com
June 13, 2019 · 12:18 p.m.
565 views
Diversity and Inclusion Panel: Bring the Thunder!
Panel
June 13, 2019 · 2:30 p.m.
244 views
Asynchronous streams in direct style with and without macros
Philipp Haller, KTH Royal Institute of Technology in Stockholm
June 13, 2019 · 3:45 p.m.
304 views
Interactive Computing with Jupyter and Almond
Sören Brunk, USU Software AG
June 13, 2019 · 3:46 p.m.
681 views
Scala best practices I wish someone'd told me about
Nicolas Rinaudo, CTO of Besedo
June 13, 2019 · 3:47 p.m.
2705 views
High performance Privacy By Design using Matryoshka & Spark
Wiem Zine El Abidine and Olivier Girardot, Scala Backend Developer at MOIA / co-founder of Lateral Thoughts
June 13, 2019 · 3:48 p.m.
754 views
Immutable Sequential Maps – Keeping order while hashed
Odd Möller
June 13, 2019 · 4:45 p.m.
277 views
All the fancy things flexible dependency management can do
Alexandre Archambault, engineer at the Scala Center
June 13, 2019 · 4:46 p.m.
389 views
ScalaWebTest - integration testing made easy
Dani Rey, Unic AG
June 13, 2019 · 4:47 p.m.
468 views
Mellite: An Integrated Development Environment for Sound
Hanns Holger Rutz, Institute of Electronic Music and Acoustics (IEM), Graz
June 13, 2019 · 4:48 p.m.
213 views
Closing panel
Panel
June 13, 2019 · 5:54 p.m.
400 views
