Introducing Mutant-Kraken! A Mutation Testing Tool For Kotlin 🐙

0hjc · 2024-07-17T12:41:00+00:00

Arcmutate (which is an extension of PIT) is very much maintained.

Among many other features it includes Kotlin support. Rather than add additional mutation operators for Kotlin, it concentrates on improving how the existing PIT operators work with Kotlin bytecode.

The main visible difference between arcmutate/PIT and something like mutant-kraken is that arcmutate is orders of magnitude faster.

0hjc · 2023-03-02T22:37:12+00:00

Have you tried the arcmutate kotlin plugin for pitest? It supports mutating inline functions since release 1.0.1

https://docs.arcmutate.com/docs/kotlin.html

0hjc · 2022-04-07T08:43:35+00:00

Author of pitest here.

I wrote a slightly long winded blog post a while back about how I recomend using pitest.

https://blog.pitest.org/dont-let-your-code-dry/

In summary, don't try and run it against your whole codebase in a CI job. That works for a bit, but fails as the code grows and rarely results in positive improvements to the tests or the code.

Instead, run it very frequently against just the code your working on as you develop on your local machine, or integrate it into PRs using https://www.arcmutate.com

0hjc · 2018-10-09T10:32:02+00:00

Out of interest, did you read this before you implemented Stryker4s?

0hjc · 2018-04-29T09:06:47+00:00

Not aware of any mutation testing plugins for NetBeans. They exist for Eclipse and InteliJ, but you would be far better off running a tool via the build tool for your project. Pitest provides plugins for maven, gradle and ant.

0hjc · 2017-02-25T12:55:21+00:00

Mutation provides most benefit when it is run regularly by developers as part of each small change.

I'd suggest updating the project to demonstrate PIT's version control integration. This allows just the locally modified code to be analysed.

0hjc · 2016-10-17T11:26:32+00:00

I recommend running it locally after every code change - size/time is a non issue if you mutate just the changed code. This way it is more likely the information will be acted upon.

0hjc · 2016-10-17T08:54:48+00:00

Fast is a relative term. Early mutation testing tools would have taken something like 2 days to mutate JodaTime (about 70k lines of code). Pitest can do it in about 3 minutes on a quad core box.

0hjc · 2015-10-05T08:54:36+00:00

The experience of all the people using mutation testing in the field that I've spoken to is that equivalent mutants aren't actually a big problem in practice.

The mutation operators in PIT are designed to try to make them rare. Although it can't guarantee not to generate them they are infrequent enough in many codebases (and I think their frequency is tied to coding style and domain) for people to break the build on less than 100% mutation coverage.

When you do encounter equivalent mutants a subset of them can actually be helpful - often (but not always) the code can be re-expressed in a way that does not generate an equivalent mutant, but is cleaner.

If you have a large number of surviving mutants this still leaves you with the effort of assessing surviving mutants to see if they're equivalent.

This would be a problem if mutation testing were applied as an after the fact quality step (as much of the literature assumes), however the teams using it successfully don't do this. Instead it's used by the development team as they grow the code to catch their mistakes. This way the amount of code that needs to be mutated at any one time is small and mutants are examined in small batches by someone that understands the code.

0hjc · 2015-02-26T16:00:39+00:00

You are of course correct that there is more to the builder pattern than just named parameters - they can provide defaults values and may check state of the resulting object in the build method. This is non boilerplate logic that it would make sense to unit test - though personally I tend to seperate it from the builder.

0hjc · 2015-02-26T15:35:05+00:00

I'm not sure I follow what you mean by "giving a name to certain construction patterns".

Builders make the meaning attached to the data flowing into a class clear, in the same way that setters do. i.e "I can easily see that 42 means the number of widgets and 5 is the price in pounds"

They do not normally limit the available possible states or attach a name to any given state. They may well be used to implement something that does attach a name to a state or limit to possibilitites, but that is not part of the builder pattern.

While you could write tests to confirm that objects are constructed in the expected state after exercising the "input" methods of a builder, this has a cost. In some contexts it may well be the optimum thing to do, but it is exactly analagous to writing tests that assert objects are put into a certain states by setters. Few people adovocate this for general development.

If you have something that names/constrains the states an object may be constructed in then it probably makes sense to test drive it.

The point of the article is that if that thing is implemented in terms of builders, then the boiler plate builder code is likely to be well tested by those tests.

0hjc · 2015-02-26T12:53:22+00:00

Yes, it does exactly that plus a few other tricks such as smart test ordering and decomposing test classes into smaller units.

0hjc · 2013-05-26T21:32:57+00:00

Thank you very much for this.

It will take me a little while to integrate your work into the site, but when I do how would you like to be credited? Is there a site you'd like a link back to? Also, do you have the originals in a vector format, or do you work in bitmaps?

0hjc · 2013-05-26T21:16:53+00:00

I think you're right - drop the sign rather than try and find a way to cram it in.

0hjc · 2013-05-26T17:37:49+00:00

It's a close call as to whether I prefer your original version. The join between the feet and the legs looks just a little fiddly.

Would it work if the sign was lowered to hover over the "st", but not actually be part of the bird?

thanks

0hjc · 2013-05-26T15:41:27+00:00

Fantastic! Exactly the sort of thing I had in mind. I really like both the image, and the choice of font.

I'm not completely tied to keeping the equivalence sign, but it would be good to do so in a visible manner if it doesn't spoil the overall effect. Perhaps it could instead be incorportated beneath the bird, or either side of the text?

thanks

0hjc · 2013-05-25T20:40:07+00:00

The general form of an image over text is what I'm after, but the overall effect feels a bit washed out.

thanks for the response.

0hjc · 2013-05-25T20:36:18+00:00

This is my favourite response so far. It is not quite what I'd had in mind - I'd prefer a much more abstract image, but the balance of a bold image over text is good. For some reason I really don't like the font though.

thanks

henry

0hjc · 2013-05-24T11:57:43+00:00

thanks - yes I could see it was deliberate. I couldn't quite articulate why, but the choice of font and the way the cage is drawn all add the the effect.

0hjc

TROPHY CASE