rails - ¿Existe un framework como Factory Girl para Java?

factorybot association

Question

Factory Girl es un marco práctico en rieles para crear fácilmente instancias de modelos para pruebas.

Desde la página de inicio de Factory Girl :

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

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

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 puede simplemente llamar

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

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

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

PD: Conozco tanto a JMock como a EasyMoc, sin embargo, no estoy hablando de un marco de burla aquí.

Answer 1

1. Entiendo que esto no es para todos, pero podría escribir el código de prueba de Ruby en su código Java. (JTestR)
2. La forma preferida de hacer esto en Java es usar el patrón Test Data Builder . Yo diría que este enfoque realmente no justifica la introducción de la complejidad de un marco o dependencia externa. Simplemente no veo cómo podría especificar mucho menos usando un marco y obtener algo más de eso ... la sintaxis de Builder es esencialmente equivalente a su sintaxis de FactoryGirl. (Alguien no dude en convencerme de lo contrario!)

Answer 2

Llegué aquí con la misma pregunta y necesité la herramienta de generación de datos para mis pruebas de integración. Decidí aceptar el desafío con Groovy, que es mi idioma de elección para las pruebas debido a su compacidad y poder .

Acabo de escribir un pequeño ayudante https://gist.github.com/pgaertig/9502960 llamado FactoryGrill;) que te permite escribir scripts de datos como se muestra a continuación.

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

Lo anterior es equivalente a:

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

Puedes 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

Realmente no es una fábrica porque las fábricas son bastante sencillas en Groovy con el constructor de mapas o expandos .

Las referencias y otras cosas de FactoryGirl no están disponibles actualmente porque lo anterior se logra solo con ~ 30LOC. Sin embargo, si hay un interés en mi solución, agregaré un proyecto dedicado a Github.

Answer 3

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

En el pasado escribí un código que usa la reflexión para rellenar los valores de los beans. La idea básica es encontrar todos los configuradores y llamar a cada uno con un valor ficticio. Mi versión configuró todas las cadenas como el nombre del campo setName se llamaría con "nombre", luego se configuran todas las cadenas como 1, booleanos como verdaderos, etc.

Luego utilicé esto en conjunción con los patrones similares a Object mother y Test Data Builder.

Proporcionó un buen comienzo para los datos de prueba y cualquier campo que requiera valores específicos podría establecerse explícitamente como parte de la prueba.

Espero que esto ayude.

Answer 4

Si los objetos de su modelo son simples, no hay razón para usar un marco para crearlos, simplemente use el operador ''nuevo''. Si tiene un modelo complejo (relaciones complejas), puede usar spring para unirlos (incluso en escenarios de prueba puede usar spring)

• pero esto es simplemente para los objetos de datos, si está hablando de crear una instancia de objetos que están haciendo algo, se recomienda simular / rechazar las relaciones externas en lugar de usar instancias reales.

Answer 5

También busqué un equivalente en Java de Factory Girl, pero nunca encontré nada igual. En su lugar, he creado una solución desde cero. Una fábrica para generar modelos en Java: Model Citizen .

Inspirado por Factory Girl, utiliza anotaciones de campo para establecer los valores predeterminados de un modelo, un ejemplo simple 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 de coche. Esto está registrado en el ModelFactory, de lo que se pueden crear nuevas instancias de la siguiente manera:

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

Puede anular los valores del modelo de Car pasando una instancia de Car en lugar de la Clase y configurando los valores según sea necesario:

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

La wiki tiene ejemplos más complejos ( como el uso de @Mapped ) y detalles para algunas campanas y silbidos más.

Answer 6

Una posible biblioteca para hacer esto es Usurper .

Sin embargo, si desea especificar las propiedades de los objetos que está creando, la tipificación estática de Java hace que un marco no tenga sentido. Tendría que especificar los nombres de las propiedades como cadenas para que el marco pueda buscar accesores de propiedades mediante la reflexión o la introspección de Java Bean. Eso haría mucho más difícil la refactorización.

Es mucho más simple simplemente renovar los objetos y llamar a sus métodos. Si desea evitar un montón de código repetitivo en las pruebas, el patrón del generador de datos de prueba puede ayudar.