2012-06-11 11 views
7

Jestem nowy w Scala (od Javy) i lubię rozwijać TDD/BDD. Zanim więc dowiem się dużo o Scali, zanurkowałem już w Scalatest.Scala - konfiguracja testu urządzenia (użyj kwalifikatorów modyfikatora dostępu?)

Zastanawiam się, co uważasz za dobrą strategię dostępu do testów jednostkowych, z punktu widzenia, który chcesz przetestować tak bardzo, jak to możliwe.

Załóżmy, że mam świat klasy, który chcę przetestować i agenta klasowego, który nie powinien wiedzieć wszystkiego o świecie.

package program { 
    package world { 
    class World { 
     private var notForAgent 
     def forAgentDuringActing 
     // forAgentDuringActing has an important side effect in notForAgent 
    } 
    } 

    package agent { 
    class Agent 
    // would call World.forAgentDuringActing 
    } 

    package world.test { 
    class WorldSpec extends FunSpec { 
     describe("The world") { 
     it("should have side-effect behaviour when the agent acts on it") { 
      // ... the test ... 
     } 
     } 
    } 
    } 
} 

Pamiętaj, że te deklaracje nie są dla mnie święte. To, co naprawdę chciałbym, to to, że WorldSpec będzie czymś w rodzaju obiektu towarzyszącego Światowi, aby mógł przetestować efekt uboczny.

Pomyślałem, że pomocne mogą być modyfikatory modyfikatorów dostępu. Mogę powiedzieć: private[world] notForAgent, ale to naprawdę jest większy dostęp, niż bym chciał. To, czego naprawdę chciałbym, to coś w rodzaju private[this, test.WorldSpec] notForAgent, ale nie sądzę, że dozwolone są wielokrotne kwalifikatory.

Co byś zrobił, aby to sprawdzić? Alternatywnie, czy możesz wskazać, gdzie moje myśli idą w złym kierunku?

p.s. Znam stwierdzenie "nigdy nie testuj szeregowców". Ale znam także opinię "Testowanie jest ważniejsze niż sam kod. Zmień modyfikatory dostępu, jeśli jest to potrzebne do testowania". Chciałbym jednak uniknąć tej dyskusji w tym wątku.

Odpowiedz

9

Jeśli pytasz "Jak testować metody prywatne?", ScalaTest faktycznie to obsługuje. Zobacz here.

class C { 
    private def m(x: Int) = x 
} 

class CTests extends /*any test suite you like*/ with PrivateMethodTester { 
    val decoratedM = PrivateMethod[Int]('m) 
    val c = new C 
    val actual = c invokePrivate decoratedM(4711) 
    val expected = 4711 
    actual should be(expected) // this line depends on the test suite you've chosen 
} 
+0

Tak, wiedziałem o tym. Jednak stan, który chcę przetestować, jest w wariancie, a nie w metodzie. Jednak twoja odpowiedź jest rzeczywiście użyteczna, ponieważ podobno Scala również robi metodę gettera dla prywatnego val. Więc możesz zrobić testy w ten sposób. Czy nie byłoby sposobu, aby pozwolić na to w bardziej naturalny sposób (jak to jest w przypadku obiektu towarzyszącego)? – qkrijger

+0

Hmm, nie mogę głosować na twoją odpowiedź, ponieważ nie mam jeszcze 15 punktów reputacji ... :( – qkrijger

+0

Teraz, kiedy wprowadzam pewne testy w ten sposób, muszę powiedzieć, że powietrze staje się trochę śmierdzące przez kod. Po pierwsze, ten test psuje się po refaktorze (co nie jest wielkim problemem, ale też nie jest czysty) .Jeżeli ktoś ma pomysły na to, jak poprawić ustawienia, to też byłoby miło. podobny do jednostki testowej obiekt, ale nie wiedziałbym, jak osiągnąć coś takiego (jeśli to możliwe) – qkrijger

Powiązane problemy