Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd6-da45-0-c0bc-40f2-c2af-8196.ipv6dyn.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: Mutation Testing (was: Bit packed array) Date: Fri, 12 Oct 2018 12:12:43 +0200 Organization: news.netcologne.de Distribution: world Message-ID: References: <935c2a6a-4cc6-4659-a9e5-ed8f85e95bb6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 12 Oct 2018 10:12:43 -0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd6-da45-0-c0bc-40f2-c2af-8196.ipv6dyn.netcologne.de:2001:4dd6:da45:0:c0bc:40f2:c2af:8196"; logging-data="5910"; mail-complaints-to="abuse@netcologne.de" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 In-Reply-To: Content-Language: en-US Xref: csiph.com de.comp.lang.java:13219 Responding to Joerg Meier: > On Wed, 10 Oct 2018 16:50:05 +0200, Patrick Roemer wrote: > >> Nur als Scherz am Rande, weil von der Idee her verwandt: Es gab da mal >> ein Tool[1], das Änderungen im Code vorgenommen hat und dann die Tests >> dagegen laufen ließ - wenn die noch grün liefen, war die geänderte >> Stelle nicht hinreichend abgedeckt. Nette Idee, aber die >> Praxistauglichkeit... > > Das ist gar nicht so laecherlich; mutation testing gibt es immer noch und > es ist mittlerweile weit genug entwickelt, um normalen unit tests um > einigest voraus zu sein. > > http://pitest.org/ Das klingt etwas schräg - Mutation Testing operiert doch gerade auf "normalen Unit-Tests" und fügt denen sozusagen noch eine Metatestebene hinzu. Ich nehme mal an, gemeint ist, dass solchermassen "gehärtete" Unit-Tests ihren Kollegen voraus sind. Gibt es denn da Erfahrungswerte mit Projekten oberhalb von Additionsserver, Fibonacci und Palindromen? Was konkretes habe ich auf Anhieb nicht gefunden. Ich würde erwarten, dass die Laufzeiten immer noch jenseits von gut und böse sind. Klingt z.B. hier auch so: "Even though mutation testing reveals defects in code, it should be used wisely, because it is an extremely costly and time-consuming process."[1] Wie auch anders - die Laufzeit muss ja mindestens (normale Laufzeit der Tests) x (Anzahl der Mutationen) sein... Weiter wäre ich skeptisch, was "false positives" angeht, also dass, ähnlich wie bei klassischer Coverage, Code angemeckert wird, der gar nicht getestet werden soll, wie etwa #toString(). Und mich würde interessieren, wie mit durch Mutationen entstandenen Endlosschleifen, etc. verfahren wird. Ich wollte den Ansatz mal spaßeshalber mit einem Scala-Framework[2] gegen eines meiner Projekte ausprobieren, bin aber sofort in einen Bug(?)[3] mit Concurrency-Konstrukten gelaufen. :/ (Was natürlich überhaupt nichts über PIT aussagt.) Viele Grüße Patrick [1] https://www.baeldung.com/java-mutation-testing-with-pitest [2] https://github.com/sugakandrey/scalamu [3] https://github.com/sugakandrey/scalamu/issues/5