Bardziej dynamiczna analiza kodu dla języka Scala - Property-based testing

Testy modułowe (jednostkowe) napisane w poście Dynamiczna analiza kodu dla projektu resentiment zawiodły. Mimo posiadania 100% pokrycia kodu dla klasy Calculator klasa ta nie działała w sposób poprawy.

To dlatego, że skupiłem się na drugiej linii definicji

Korzystanie z metryk testów, takich jak pokrycie kodu, zapewnia, że przetestowano odpowiednią ilość możliwych zachować programu

Zapominając jednocześnie o trzeciej:

Aby analiza dynamiczna programu była skuteczna, program docelowy musi być wykonany z wystarczającą ilością danych wejściowych do testów, aby uzyskać interesujące zachowanie.

Problem można rozwiązać za pomocą property-based testing

Property-based testing (Testowanie oparte na właściwościach)

Przy pisaniu normalnych testów, czyli modułowych (jednostkowych), integracyjnych i systemowych, wyznaczamy przypadki brzegowe i klasy równoważności. Chcemy by danych testowych było jak najmniej, tak by testy wykonywały się jak najszybciej.

W przypadku property-based testing jest inaczej. Tutaj zamiast wyznaczać konkretne dane wejściowe definiujemy tylko ogólne ograniczenia jakie mają spełniać dane. Na podstawie ograniczeń generowane są dane wejściowe dla testów. Dużo danych wejściowych. Dlatego testy te są wolne, chociaż testują pojedyncze moduły i jednostki.

Biblioteki dla property-based testing w języku Scala

  • ScalaCheck - pierwsza i najbardziej popularna biblioteka property-based testing. Wspiera Scala.js w wersji 0.6 i 1.0.0. Inspirowana biblioteką QuickCheck dla języka Haskell. Jeden z projektów typelevel. Posiada integracje z ScalaTest i Specs2.
  • scalaprops - druga najbardziej popularna biblioteka property-based testing. Wspiera Scala.js w wersji 0.6 i Scala Native w wersji 0.3. Posiada integrację z biblioteką Scalaz.
  • Nyaya - projekt niestety umarł. Wspierał Scala.js w wersji 0.6.

Testowanie oparte na właściwościach za pomocą ScalaProps

Ponieważ chcę utrzymać możliwość kompilacji krzyżowej (cross compilation), wybieram bibliotekę scalaprops dla testów.

Dodajemy wtyczkę sbt-scalaprops do pliku project/plugins.sbt:

addSbtPlugin("com.github.scalaprops" % "sbt-scalaprops" % "0.2.6")

Dodajemy wymagane zależności do libraryDependencies:

  libraryDependencies ++= Seq(
    "com.github.scalaprops" %%% "scalaprops" % ScalaPropsVersion % "test,it",
    "com.github.scalaprops" %%% "scalaprops-scalazlaws" % ScalaPropsVersion % "test,it",
  ),

Ponieważ testy jednostkowe powinny być szybkie, konfigurujemy scalaprops jako testy integracyjne.

Na początku musimy dodać do cross-projektu ustawienia dla scalaprops za pomocą linii:

lazy val re = crossProject(JSPlatform, JVMPlatform, NativePlatform)
  // ...
  .settings(scalapropsCoreSettings)

Następnie musimy wskazać folder, który będzie zawierać testy integracyjne:

lazy val re = crossProject(JSPlatform, JVMPlatform, NativePlatform)
  // ...
  .settings(
    unmanagedSourceDirectories in IntegrationTest ++= CrossType.Full.sharedSrcDir(baseDirectory.value, "it").toSeq
  )

Niestety Scala Native nie wspiera obecnie testów integracyjnych. Może kiedyś będzie wspierać, może jak będę miał czas sam ogarnę makra i napiszę stosownego pull-requesta. Do tego czasu będzie mi o tym przypominać zakomentowana linia:

lazy val re = crossProject(JSPlatform, JVMPlatform, NativePlatform)
  // ...
  //.nativeSettings(scalapropsNativeSettings)

Ostatecznie konfiguracja projektu wygląda następująco:

lazy val re = crossProject(JSPlatform, JVMPlatform, NativePlatform)
  .withoutSuffixFor(NativePlatform)
  .crossType(CrossType.Full)
  .settings(SharedSettings)
  .jsSettings(jsSettings)
  .jvmSettings(jvmSettings)
  .nativeSettings(nativeSettings)
  // IntegrationTest
  .configs(IntegrationTest)
  .settings(Defaults.itSettings)
  .settings(
    inConfig(IntegrationTest)(scalafixConfigSettings(IntegrationTest)),
    inConfig(IntegrationTest)(ScalafmtPlugin.scalafmtConfigSettings),
    inConfig(IntegrationTest)(scalariformItSettings),
    unmanagedSourceDirectories in IntegrationTest ++= CrossType.Full.sharedSrcDir(baseDirectory.value, "it").toSeq
  )
  .jsSettings(inConfig(IntegrationTest)(ScalaJSPlugin.testConfigSettings))
  .nativeSettings(inConfig(IntegrationTest)(Defaults.testSettings))
  // PropsTest
  .settings(scalapropsCoreSettings)
  //.nativeSettings(scalapropsNativeSettings)

W folderze re/shared/src/it/scala/ tworzymy testy dla klasy pl.writeonly.re.shared.Calculator:

package pl.writeonly.re.shared

import scalaprops.{ Property, Scalaprops }

object CalculatorIT extends Scalaprops {
  val calculator = new Calculator()

  val addition: (Int, Int) => Int = (x, y) => calculator.add(x, y)
  val additionTest = Property.forAll { (a: Int, b: Int) =>
    addition(a, b) == a + b
  }

  val multiplication: (Int, Int) => Int = (x, y) => calculator.mul(x, y)
  val multiplicationTest = Property.forAll { (a: Int, b: Int) =>
    multiplication(a, b) == a * b
  }

  val lessOrEqual: (Int, Int) => Boolean = (x, y) => calculator.leq(x, y)
  val lessOrEqualTest = Property.forAll { (a: Int, b: Int) =>
    lessOrEqual(a, b) == (a <= b)
  }
}

Wywołujemy:

sbt clean coverage reJS/it:test reJVM/it:test

I naszym oczom powinien ukazać się piękny komunikat:

pl.writeonly.re.shared.CalculatorIT$ 
+- additionTest  Falsified(0,0,[Arg(0, 18591416),Arg(0, 241819340)],LongSeed(1542137236582000128)) 4ms
+- lessOrEqualTest ................................................. Passed(50,0,LongSeed(1542137236604999936)) 11ms
`- multiplicationTest  Falsified(0,0,[Arg(0, -795557759),Arg(0, -1)],LongSeed(1542137236617999872)) 0ms
[error] falsified CalculatorIT additionTest Falsified(0,0,[Arg(0, 18591416),Arg(0, 241819340)],LongSeed(1542137236582000128))
[error] falsified CalculatorIT multiplicationTest Falsified(0,0,[Arg(0, -795557759),Arg(0, -1)],LongSeed(1542137236617999872))
[info] pl.writeonly.re.shared.CalculatorIT$ 39 ms
11 pl.writeonly.re.shared.CalculatorIT$.lessOrEqualTest 50 50
4 pl.writeonly.re.shared.CalculatorIT$.additionTest 50 50
0 pl.writeonly.re.shared.CalculatorIT$.multiplicationTest 50 50
[info] 11 pl.writeonly.re.shared.CalculatorIT$.lessOrEqualTest 50 50
[info] 4 pl.writeonly.re.shared.CalculatorIT$.additionTest 50 50
[info] 0 pl.writeonly.re.shared.CalculatorIT$.multiplicationTest 50 50
[error] Failed tests:
[error] 	pl.writeonly.re.shared.CalculatorIT
[error] (reJS / IntegrationTest / test) sbt.TestsFailedException: Tests unsuccessful

Testy nie przeszły, mamy błąd w kodzie. W związku z tym poprawiamy klasę Calculator:

package pl.writeonly.re.shared

class Calculator {
  type T = Int

  def add(a: T, b: T): T = a + b

  def mul(a: T, b: T): T = a * b

  def leq(a: T, b: T): Boolean = a < b

}

I ponownie wywołujemy:

sbt clean coverage reJS/it:test reJVM/it:test

Teraz dostajemy poprawną odpowiedź:

pl.writeonly.re.shared.CalculatorIT$ 
+- additionTest ................................................. Passed(50,0,LongSeed(1542137486777999872)) 12ms
+- lessOrEqualTest ................................................. Passed(50,0,LongSeed(1542137486793999872)) 5ms
`- multiplicationTest ................................................. Passed(50,0,LongSeed(1542137486800999936)) 5ms
[info] pl.writeonly.re.shared.CalculatorIT$ 31 ms
12 pl.writeonly.re.shared.CalculatorIT$.additionTest 50 50
5 pl.writeonly.re.shared.CalculatorIT$.lessOrEqualTest 50 50
5 pl.writeonly.re.shared.CalculatorIT$.multiplicationTest 50 50
[info] 12 pl.writeonly.re.shared.CalculatorIT$.additionTest 50 50
[info] 5 pl.writeonly.re.shared.CalculatorIT$.lessOrEqualTest 50 50
[info] 5 pl.writeonly.re.shared.CalculatorIT$.multiplicationTest 50 50

Ostatecznie moja pełna komenda do kompilacji to:

sbt scalafix test:scalafix it:scalafix && \
sbt scalafmtSbt scalafmt test:scalafmt it:scalafmt && \
sbt clean compile test:compile it:compile re/test && \
sbt coverage reJS/test reJVM/test reJS/it:test reJVM/it:test && \
sbt coverageReport && \
sbt scalastyle test:scalastyle it:scalastyle && \
sbt scapegoat cpd stats

Smutne podsumowania

Klasyczne testy modułowe (jednostkowe) nie wystarczają, ponieważ prawnie napisane testy modułowe, które pokrywają 100% kodu aplikacji, mogą być niepoprawne, jeśli dane wejściowe są źle dobrane.

Flagi kompilatora Scalac

Nie bójmy się tego powiedzieć, Scala to nowy Perl. I tak jak w Perlu, w Scali obowiązuje zasada TIMTOWTDI (ang. There is more than one way to do it), czyli “Można to zrobić na różne sposoby”.

Jednak z biegiem czasu twórcy języka Scala uznali, że niektóre sposoby są lepsze od innych i powinna istnieć możliwość wyłączenia gorszych sposobów. Dodatkowo niektóre funkcjonalności języka są tak inne od tego co do tej pory widzieli programiści języków obiektowych, że nie powinny być domyślnie włączone. Oba te warunki, i pewnie jeszcze kilka innych, powodują, że Scalac, kompilator języka Scala, posiada flagi kompilacji. Dokładniej Scalac posiada ogromną ilość flag kompilacji.

Rekomendowana lista flag kompilatora

Na szczęście istnieją tacy ludzie jak tpolecat, który na swoim blogu zebrał listę rekomendowanych flag kompilatora Są to:

scalacOptions ++= Seq(
  "-deprecation",                      // Emit warning and location for usages of deprecated APIs.
  "-encoding", "utf-8",                // Specify character encoding used by source files.
  "-explaintypes",                     // Explain type errors in more detail.
  "-feature",                          // Emit warning and location for usages of features that should be imported explicitly.
  "-language:existentials",            // Existential types (besides wildcard types) can be written and inferred
  "-language:experimental.macros",     // Allow macro definition (besides implementation and application)
  "-language:higherKinds",             // Allow higher-kinded types
  "-language:implicitConversions",     // Allow definition of implicit functions called views
  "-unchecked",                        // Enable additional warnings where generated code depends on assumptions.
  "-Xcheckinit",                       // Wrap field accessors to throw an exception on uninitialized access.
  "-Xfatal-warnings",                  // Fail the compilation if there are any warnings.
  "-Xfuture",                          // Turn on future language features.
  "-Xlint:adapted-args",               // Warn if an argument list is modified to match the receiver.
  "-Xlint:by-name-right-associative",  // By-name parameter of right associative operator.
  "-Xlint:constant",                   // Evaluation of a constant arithmetic expression results in an error.
  "-Xlint:delayedinit-select",         // Selecting member of DelayedInit.
  "-Xlint:doc-detached",               // A Scaladoc comment appears to be detached from its element.
  "-Xlint:inaccessible",               // Warn about inaccessible types in method signatures.
  "-Xlint:infer-any",                  // Warn when a type argument is inferred to be `Any`.
  "-Xlint:missing-interpolator",       // A string literal appears to be missing an interpolator id.
  "-Xlint:nullary-override",           // Warn when non-nullary `def f()' overrides nullary `def f'.
  "-Xlint:nullary-unit",               // Warn when nullary methods return Unit.
  "-Xlint:option-implicit",            // Option.apply used implicit view.
  "-Xlint:package-object-classes",     // Class or object defined in package object.
  "-Xlint:poly-implicit-overload",     // Parameterized overloaded implicit methods are not visible as view bounds.
  "-Xlint:private-shadow",             // A private field (or class parameter) shadows a superclass field.
  "-Xlint:stars-align",                // Pattern sequence wildcard must align with sequence component.
  "-Xlint:type-parameter-shadow",      // A local type parameter shadows a type already in scope.
  "-Xlint:unsound-match",              // Pattern match may not be typesafe.
  "-Yno-adapted-args",                 // Do not adapt an argument list (either by inserting () or creating a tuple) to match the receiver.
  "-Ypartial-unification",             // Enable partial unification in type constructor inference
  "-Ywarn-dead-code",                  // Warn when dead code is identified.
  "-Ywarn-extra-implicit",             // Warn when more than one implicit parameter section is defined.
  "-Ywarn-inaccessible",               // Warn about inaccessible types in method signatures.
  "-Ywarn-infer-any",                  // Warn when a type argument is inferred to be `Any`.
  "-Ywarn-nullary-override",           // Warn when non-nullary `def f()' overrides nullary `def f'.
  "-Ywarn-nullary-unit",               // Warn when nullary methods return Unit.
  "-Ywarn-numeric-widen",              // Warn when numerics are widened.
  "-Ywarn-unused:implicits",           // Warn if an implicit parameter is unused.
  "-Ywarn-unused:imports",             // Warn if an import selector is not referenced.
  "-Ywarn-unused:locals",              // Warn if a local definition is unused.
  "-Ywarn-unused:params",              // Warn if a value parameter is unused.
  "-Ywarn-unused:patvars",             // Warn if a variable bound in a pattern is unused.
  "-Ywarn-unused:privates",            // Warn if a private member is unused.
  "-Ywarn-value-discard"               // Warn when non-Unit expression results are unused.
)

Lista jest długa i działa dla języka Scala w wersji 2.12. Jeśli używasz języka Scala w wersji wcześniejszej to część flag będziesz musiał wyłączyć. Dla wersji 2.11 jest to:

scalacOptions --= Seq(
  "-Xlint:constant",
  "-Ywarn-extra-implicit",
  "-Ywarn-unused:implicits",
  "-Ywarn-unused:imports",
  "-Ywarn-unused:locals",
  "-Ywarn-unused:params",
  "-Ywarn-unused:patvars",
  "-Ywarn-unused:privates",
)

.. i wtyczka do nich

Lista opcji jest długa i może zaciemniać plik build.sbt. Na szczęście DavidGregory084 stworzył wtyczkę sbt-tpolecat dodającą flagi kompilatora do projektu.

W pliku ` project/plugins.sbt` dodajemy:

addSbtPlugin("io.github.davidgregory084" % "sbt-tpolecat" % "0.1.4")

i wtyczka automatycznie ustawia odpowiednie flagi dla wersji 2.10/2.11/2.12/2.13

Portable Scala & Multi-project

Jeśli kompilujesz projekt w Scali na różne platformy (JVM/JS/Native) lub posiadasz multi-project, tak jak ja w projekcie resentiment, to musisz ręcznie dodać flagi dla kompilatora. Flagi generuje metoda scalacOptionsFor, która jako parametr pobiera wersję języka Scala. Flagi dodajemy do każdego projektu z osobna lub do wydzielonych ustawień jak w moim przypadku:

val SharedSettings = Seq(
  scalaVersion := "2.11.12",
  scalacOptions ++= scalacOptionsFor(scalaVersion.value),
  // ...
)

ScalaFix i modyfikacja domyślnych flag

Właśnie ustawiliśmy ponad 30 różnych flag, ale pewnie w niektórych wypadkach chciałbyś zmodyfikować tę listę. Np. żeby móc używać wtyczki ScalaFix.

Wtyczka ta wymaga dodania dwóch flag (-Ywarn-adapted-args, -Ywarn-unused") oraz usunięcia jednej (-Xfatal-warnings). Dla wygody, flagi przypisuję do zmiennych, a następnie dodaje do scalacOptions.

val ScalaFixScalacOptions = Seq(
  "-Ywarn-adapted-args", // for NoAutoTupling
  "-Ywarn-unused", // for RemoveUnused
)

val ScalaFixScalacOptionsOff = Seq(
  "-Xfatal-warnings",   // it should be disabled for scalafix
)

val SharedSettings = Seq(
  scalaVersion := "2.11.12",
  scalacOptions ++= scalacOptionsFor(scalaVersion.value),
  scalacOptions ++= ScalaFixScalacOptions,
  scalacOptions --= ScalaFixScalacOptionsOff,
  // ...
)

W identyczny sposób można włączać i wyłączać każdą inną flagę kompilatora Scalac.

Follow