Pregunta

Factory Girl es un marco útil en los carriles para crear fácilmente los casos de modelos para la prueba.

Desde el Factory Girl página de inicio :

  

factory_girl le permite definir rápidamente prototipos para cada uno de sus modelos y pedir instancias con propiedades que son importantes para la prueba en cuestión.

Un ejemplo (también desde la página principal):

Factory.sequence :email do |n|
    "somebody#{n}@example.com"
end

# Let's define a factory for the User model. The class name is guessed from the
# factory name.
Factory.define :user do |f|
    # These properties are set statically, and are evaluated when the factory is
    # defined.
    f.first_name 'John'
    f.last_name  'Doe'
    f.admin      false
    # This property is set "lazily." The block will be called whenever an
    # instance is generated, and the return value of the block is used as the
    # value for the attribute.
    f.email      { Factory.next(:email) }
end

si necesito un usuario de un solo pueden llamar

test_user = Factory(:user, :admin => true)

que producirá un usuario con todas las propiedades especificadas en el prototipo de la fábrica, excepto para la propiedad de administración que he especificado explícitamente. También tenga en cuenta que el método de fábrica correo electrónico producirá un correo electrónico diferente cada vez que se llama.

Estoy pensando que debería ser bastante fácil de implementar algo similar para Java, pero no quiero que reinventar la rueda.

P.S: Yo sé tanto JMock y EasyMoc, sin embargo yo no estoy hablando de un marco de burla aquí

.
¿Fue útil?

Solución

Una posible biblioteca para hacer esto es usurpador .

Sin embargo, si desea especificar propiedades de los objetos que está creando, a continuación, tipos estáticos de Java hace un marco sin sentido. Habría que especificar los nombres de las propiedades como cadenas de modo que el marco podría mirar hacia arriba de acceso de propiedad que utilizan la reflexión o introspección Java Bean. Eso haría que la refactorización mucho más difícil.

Es mucho más simple que acaba nuevos hasta los objetos y llamar a sus métodos. Si se quiere evitar una gran cantidad de código repetitivo en las pruebas, la Carta de ajuste de datos Constructor puede ayudar.

Otros consejos

También busqué un equivalente Java de Factory Girl, pero nunca he encontrado nada igual. En lugar de ello, he creado una solución a partir de cero. Una fábrica para la generación de modelos en Java:. ciudadano modelo

Inspirado en Factory Girl, utiliza anotaciones de campo para establecer los valores predeterminados para un modelo, un ejemplo sencillo de la wiki :

@Blueprint(Car.class)
public class CarBlueprint {

    @Default
    String make = "car make";

    @Default
    String manufacturer = "car manufacturer";

    @Default
    Integer mileage = 100;

    @Default
    Map status = new HashMap();
}

Este sería el modelo para el modelo del coche. Esto se ha registrado en el ModelFactory, de nuevas instancias pueden ser creados como sigue:

ModelFactory modelFactory = new ModelFactory();
modelFactory.registerBlueprint( CarBlueprint.class );
Car car = modelFactory.createModel(Car.class);

Puede anular los valores del modelo de coche al pasar en una instancia de coches en lugar de la clase y el establecimiento de los valores según sea necesario:

Car car = new Car();
car.setMake( "mustang" );
car = modelFactory.createModel( car );

El wiki tiene ejemplos más complejos ( como el uso de @Mapped ) y los detalles por unos más campanas y silbatos.

  1. Entiendo que esto no es para todo el mundo, pero podría escribir código de prueba de Ruby en contra de su código Java. (JTestR)
  2. La mejor forma de hacer esto en Java está utilizando el patrón de datos de prueba Constructor . Yo diría que este enfoque en realidad no garantiza la introducción de la complejidad de un marco o dependencia externa. Simplemente no veo cómo se podría especificar mucho menos usando un marco y conseguir algo más de ella ... la sintaxis Builder es esencialmente equivalente a la sintaxis factorygirl. (Que alguien se sienta libre de convencerme de lo contrario!)

Sé que esto no es exactamente lo que está buscando ...

Yo el pasado he escrito algo de código que el uso de la reflexión para rellenar un valor frijoles. La idea básica es encontrar todos los emisores y llamar a cada uno con un valor ficticio. Mi versión establece todas las cadenas como el nombre del campo setName sería llamado con "nombre", a continuación, establecer todos los enteros como 1, booleanos true etc.

Entonces utilicé esto en conjunción con los patrones similares a Objeto madre y datos de prueba del constructor.

Se proporcionó un buen comienzo para los datos de prueba y los campos que requieren valores específicos se podría establecer explícitamente como parte de la prueba.

Espero que esto ayude.

llegué aquí con la misma pregunta y necesitaba para la herramienta de generación de los datos de mis pruebas de integración. Decidí aceptar el reto con Groovy, que es mi idioma de su elección para las pruebas debido a su tamaño compacto y aserción poder .

acabo de escribir un pequeño ayudante https://gist.github.com/pgaertig/9502960 llamada FactoryGrill;), que le permite escribir guiones de datos, como a continuación

.
insert('MyTable', ID: 1, CREATED_AT: new Date(), NAME: 'Example text')

arriba es equivalente a:

INSERT INTO MyTable(ID, CREATED_AT, NAME) VALUES (1, ..current date here.., 'Example text')

Puede hacer más con Groovy:

import org.apache.commons.lang3.RandomStringUtils;

for ( i in 0..9 ) {
     insert('USERS', CREATED_AT: new Date(), EMAIL: "test${i}@mydomain.com",
                     SALT: RandomStringUtils.randomAlphanumeric(32));
}

load(new File('usersettings.groovy').text)    //script nesting etc

No es realmente la fábrica porque las fábricas son bastante sencillo en el maravilloso con el mapa constructor o expandos .

Las referencias y otras cosas de factorygirl no está disponible actualmente debido anterior se consigue únicamente con ~ 30LOC. Sin embargo, si existe un interés en mi solución Tengo que añadir que un proyecto dedicado en Github.

Si los objetos del modelo son simples, no hay razón para utilizar un marco para crearlos, simplemente utilizar 'nuevo' operador. Si tiene complejo modelo (relaciones complejas) entonces se puede usar un muelle para atarlos juntos (incluso en escenarios de prueba se puede usar un muelle)

  • pero esto es simplemente para objetos de datos, si usted está hablando de crear instancias de objetos que están haciendo algo, su recomendado para burlarse / talón de las relaciones externas en lugar de utilizar casos reales.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top