≈
home ·
quickstart ·
faq ·
downloads ·
blog ·
email ·
rss
≈
Well, not so much as roadmap as a set of hazy directions received from an untrustworthy stranger and hastly scribbled down on the back of an envelope.
Generally speaking defect fixes will be given priority above things in the lists below. Releases will be pushed out following any major defect fixes, or when a reasonable number of interesting new features have been implemented.
Distributed testing. Early versions of PIT had working support for this using hazelcast. It had some minor issues, but was made inaccessible in favour of getting the basics right. The code is still there, but has not been maintained as other things have moved on. It adds a great deal of complexity to the codebase and a decision will need to be made at some point on whether it should be ressurected or removed entirely in order to simplify things. Original distributed code has been removed, when distribution is looked at again will probably be implemented via different strategy.
Some form of equivalent mutation detection. Not sure what approach would be taken, but there’s plenty of accademic reasearch in this area to draw on. Perhaps something fine grained that takes into account the type of the mutation operator.
Mutation operators for concurrency based on mutation operators for concurrent java ≈ help?
Annotations to mark code not to be mutated. Possibly quite useful, but conceptutally polluting your production code with a testing concern is wrong.
More intelligent block based coverage. The line coverage implementation currently used by PIT is fairly basic, and could be improved in terms of both performance and the information it gathers. A block based approach would potentially allow PIT to target tests more narrowly in some circumstances and also report partial line coverage. One obvious way to achieve this would be to use a third party implementation such as JaCoCo (it would help if JaCoCo was available from maven central).
There are a number of things within the code base that while functional and defect free are embarassing, dirty or just plain wrong. These need to be polished, refactored, or re-written alongside the other work.