Scala: configuración de prueba unitaria (¿usar modificadores de modificadores de acceso?)

Question

Soy nuevo en Scala (de Java) y me gusta desarrollar TDD/BDD. Entonces, antes de saber mucho sobre Scala, ya me he zambullido en Scalatest.

Me pregunto cuál es la mejor estrategia de acceso para las pruebas unitarias, desde el punto de vista que desea probar tanto como sea posible.

Supongamos que tengo una clase World que quiero probar y un agente de clase que no debería saber todo sobre el mundo.

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 ... 
     } 
     } 
    } 
    } 
} 

Tenga en cuenta que estas declaraciones de paquetes no son sagradas para mí. Lo que realmente me gustaría es que WorldSpec sea algo así como un objeto complementario de World, para que pueda probar el efecto secundario.

Pensé que tal vez acceder a los modificadores de modificador ayudaría. Podría decir private[world] notForAgent, pero eso realmente es más acceso del que me gustaría. Lo que realmente me gustaría es algo así como private[this, test.WorldSpec] notForAgent, pero no creo que se permitan múltiples calificadores.

¿Qué harías para que esto sea comprobable? Alternativamente, ¿puedes indicar a dónde van mis pensamientos en la dirección incorrecta?

p.s. Sé que la frase "nunca pruebes a los soldados rasos". Pero también sé la opinión: "Las pruebas son más importantes que el código en sí. Altere los modificadores de acceso si es necesario para la prueba". Sin embargo, me gustaría evitar esa discusión en este hilo.

Answer 1

Si está preguntando "¿Cómo probar métodos privados?", Entonces ScalaTest realmente lo admite. Ver 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 
}