F!+N3zz3 3s !D3mp!3r3 PDF

iDempiere FitNesse
Copyright (C) 2015 Redhuan D. Oon
ESTO ES UN DOCUMENTO IROSES* DE ASEGURAMIENTO DE

CALIDAD PARA PROMOVER UN ESTÁNDAR ELEVADO DE LA
IMPLEMENTACIÓN PROFESIONAL DE UNA DISTRIBUCIIÓN LIBRE DE
ERP. LA DISTRIBUCIÓN LIBRE Y TRADUCCIÓN ES PERMITIDA
SIEMPRE QUE LOS DERECHOS DEL AUTOR O COPYRIGHT(S)
PERMANEZCAN INTACTOS
Traducción: Arturo Pérez

( iapp.com.mx@gmail.com arturo@iapp.com.mx )
original: http://red1.org/iDempiereFitNesse.pdf
*IROSES ES UNA SOCIEDAD DE IDEAS (JOINT BRAIN-CHILD) EN

PROCESO DE FORMACIÓN CON UN GRAN FAN Y AMIGO, UN GRAN
USUARIO DE IDEMPIER Y COLABORADOR LOCALIZADO EN
ALEMANIA. HERR ANDREAS THIEL, RESIDE EN SAARBRÜCKEN,
ALEMMANIA. ESTE ES EL LINK A SU CONTRIBUCIÓN -
HTTP://WIKI.IDEMPIERE.ORG/EN/AULERSIPEL ¡HEIL THIEL!
iROSES iDempiere FitNesse
iDempiere FitNesse
Marco de pruebas para software ERP de excelencia
Por:
Redhuan D. Oon alias red1.
(Documento iniciado en principios de septiembre de 2015 in
Mexico City, a una hora de Victor Pérez, en Pachuca, quien tomó
ofensiva de mis feroces revisiones de sus módulos Libero al grado
de remover mi nombre de la página wiki del historial de ADempiere
y se puso él mismo en mi lugar. Él me llamó por teléfono cuando
escucho que yo había arribado, para decir: "¡Hola soya amigo!").
October 6, 2015
version 0.7
Este documento es parte de una serie de pruebas que cubre varios
plugins como Localización en Alemania, Pronóstico, Presupuesto,
Manufactura, Integración con punto de venta, Integración móvil y
administración de almacenes.
También incluye una guía operativa para introducción al nuevo

módulo de pronóstico (páginas 25-39).
Muchos agradecimientos a Zeeshan Hasan, de SYSNOVA,

Bangladesh, por su inquebrantable apoyo a largo plazo.
TRES LEYES DE RED1:

La información es gratuita
TÚ TIENES QUE SABER
Las personas no lo son
TÚ TIENES QUE PAGAR
Los colaboradores no tienen precio

TÚ TIENES QUE SER
cualquier comentario o any comment or retroalimentación sobre

el contenido de este material puede ser enviado por correo a
red1org@gmail.com o red1@red1.org o red1@adempiere.org
Page 2 of 45 Copyright (C) 2015 Redhuan D. Oon

patrocinado por
BANGLADESH
ES MEJOR QUE CUALQUIER PETICIÓN DE ASISTENCIA SEA

HECHA A LA COMUNIDAD O A TRAVÉS DE FOROS. SOMOS
MÁS EFECTIVOS AYUDÁNDOTE COLECTIVAMENTE EN
LUGAR DE PARTICULARMENTE. POR FAVOR SÉ
CONSIDERADO CONRTIBUYENDO POSTERIORMENTE O
PATROCINANDO OTROS TRABAJOS Y A CUALQUIERA DE
LOS COLABORADORES. TÚ TAMBIÉN SERÁS APRECIADO.
Decir a alguien que ellos

están equivocados se
llama crítica.
Hacerlo oficialmente se
llaman pruebas.

Contenido
Omisión 6
Intenta los ejemplos ahora 6
Algunas cosas sobre mí 7
Mejor aplicación de código abierto (open source) 9
Importancia de las pruebas de software 10
Características 12
Mi mejora para la Restauración (Roll Back) 13
Creación de grabación automática (Record Auto) 14
Manejo de la ventana de información (Info Window) 15
Guía de usuario para desarrolladores 16

Configuración para desarrollador 16
Crear una prueba nueva 16
La opción de restauración (Roll Back) o la opción Commit 19
Lectura de registro 20
Localización del historial fixture 21
Localización del código fuente 21
Suite de prueba predefinida 22
Prueba rápida 22
Prueba de efectivo para orden de punto de venta (POS) 23
Proceso de ejecución (Run Process) 24
Registro de confirmación (Assert Record) 24
Variable de confirmación 25
Pronóstico (Forecasting) 26
Reutilizando el modelo de pronóstico (Forecast Model) 27
Estructura del menú (Menu Structure) del pronóstico 28
Ventana de información (Info Window) del programa de ventas 29
Prueba del presupuesto (Testing Budget) para pronóstico de ventas 30
Ventana de información del pronóstico de compras (Purchasing Forecast) 31
Prueba de pronóstico PO hacia PO 32
Probando ordenes de venta para pronóstico 33
Probando el modelo de procesamiento para el pronóstico 34
Prueba del plazo de ejecución (Lead Tme) para entrega 35
Prueba de la cantidad (Qty) del Balance 37
Prueba del balance invertido (Reversed Balance) 38
Plazo de ejecución (Lead Time) de ventas directas 39
Poniendo todo junto 40
Localización en Alemania (German Localisation) 41

Fabricación 42
Almacenamiento 43
Punto de venta (POS) 44
Aplicaciones móviles 45
Vamos a tratar de eso significa no más Me alegro de que esto
algo que se llama la planificación y no más tiene un nombre.
programación ágil documentación. Solo
empezar a escribir Ese fue su
código y quejarse entrenamiento.

Omisión
Intenta los ejemplos ahora

Ir a: http://sourceforge.net/projects/red1/files/Testing/
(A) Instala org.idempiere.fitnesse.fixture_< timestamp >.jar y

org.purchasing.forecast<>.jar en la consola de tu servidor
idempiere OSGi.
(B) Reemplaza FitNesseRoot dentro del directorio /fitnesse/FitNesseRoot
Para aprender más, sigue y pregunta en mi foro:
http://red1.org/adempiere/viewtopic.php?f=28&t=1813
ESTE TRABAJO ES PATROCINADO POR
SYSNOVA, BANGLADESH
Si deseas aportar algo adicional para mí viaje y el de mi hijo de 15 años

alrededor del mundo en busca de la libertad y felicidad, aventura y
conocimiento, esta es mi cuenta paypal - red1@red1.org

Algunas cosas sobre mí

Hay algo que tú posiblemente no sepas de mí. De hecho yo soy uno de los muy pocos
expertos certificados en pruebas (testing) por aquí. Sí, yo tengo un certificado para
probar esto. Aquí está..
Como se puede ver, incluso me da la autoridad para usar una insignia de certificador.
Haré una y la llevaré al camina siempre que haya un fallo de software en la ciudad. El
CTFL tiene bastante tiempo y puede haber expirado. Pero la última vez que lo revisé, la
doctrina para las pruebas (testing) es la misma.
De todos modos, ¿Qué aprendí durante el curso antes de pasar los exámenes para este
certificado?. Así que aquí está, las cosas más importantes que me sorprendieron
durante el curso.
1. Piensa por qué se debe probar. ¿Te subirías abordo de un avión que no ha sido
probado? Por supuesto se prueba, todo el mundo lo asume. De lo contrario no volaría.
2. Las pruebas son más costosas que el desarrollo. Sí, me oyes bien. O yo he oído mal
al conferencista. En Microsoft, hay 5 ingenieros de pruebas (testers) por cada
desarrollador, y en Adobe, hay 20 ingenieros de pruebas por cada desarrollador.
3. Las pruebas de software comienzan con la revisión de los requerimientos y

especificaciones. Sí, otra vez, me escuchas bien. Esto no comienza con el código. Si
algo no está especificado correctamente, sin la documentación ¿entonces para qué
diablos se está probando el código?

4. Cada costo de oportunidad de pruebas debe calcularse y especificarse. Si no se
toma una cierta prueba, ¿Cuál será el costo de la falla de ese porción de código?
¿Cuál es la prima de seguro en esto?. Si una orden de ventas es incorrecta,
¿Cuánto está dispuesto a perder el usuario?. La falla de una cámara de seguridad
que guarda un perro, o que guarda una bóveda de un banco, los costos son
diferentes.
5. No probarse a sí mismo. Sí, me oyes bien. Un código no debe ser probado por ti
mismo porque, obviamente existe tendencia y prejuicio, pero por otra persona que
definitivamente tiene mayor tendencia y prejuicio (en contra tuya). De hecho, la
misma empresa no debe ser quien ponga a prueba el código hecho dentro de la
empresa. Esto debe ser realizado por una empresa de terceros. Mejor aún, si esa
empresa se encuentra fuera del país y es especializada y enfocada únicamente en
las pruebas de software.
Así que por favor, ahora, responde esta pregunta. ¿Alguna vez, has pensado dejar que
tu software se utilice en tu negocio o fábrica, sin que alguien como yo lo pruebe?
Profesor Dr. Jesús Zavala Ruiz, quien trabaja en la teoría de Auto-

Organización del Software de Código Abierto aquí en la Universidad
Autónoma de Chapingo, México. Él es obviamente muy impresionado
cuando yo le muestro mi motor de pruebas y mi certificado anterior.
Mi hijo de 15 años, por otro lado no lo está. Obviamente, él es
extremadamente celoso porque no posee dicha certificación. Lo he
sacado de la escuela para que me siga por todo el mundo por lo que
él no tendrá nunca la oportunidad de poseer alguno.

Mejor aplicación de Código Abierto (Open Source)
Hablando acerca de poner en una insignia, el 16 de septiembre, Infoworld, la famosa
revista en línea de Tecnología de la Información (TI), anunció iDempiere como la mejor
aplicación de software de código abierto, citando:
“Pequeñas y medianas empresas tienen grandes opciones en Odoo y

xTuple. Empresas de fabricación y distribución más grandes
necesitarán algo más. Para ellos, existe iDempiere -- una rama con
gran soporte de ADempiere con modularidad OSGi.”
iDempiere, ahora es declarado por una fuente externa independiente de código, sin
ningún tipo de solicitud comercial de nuestra parte, ser una aplicación ERP de calidad
superior, sobre Odoo y xTuple y dentro de nuestra pista de poderosas aplicaciones
claramente venciendo a Openbravo, ADempiere y Comiere. Teniendo en cuenta que los
otros son fuertemente financiandos con oficinas corporativas, campañas en los medios,
mercenarios pagados y código semicerrado debido a los modelos de negocios bien
pensados y excluyentes.
En iDempiere no tenemos nada de lo anterior y sin embargo les ganamos. No podemos

cerrar ya que no hay fondo de capital riesgo prestado para pagar y nadie en la nómina
para ser despedido. No hay Director General (CEO) que huya con botín. No hay oficina
central para ser bombardeados.
Importancia de las pruebas de software
La pantalla de abajo pinta todas las palabras necesarias para explicar la importancia de
las pruebas. Es una salida después de hacer clic en el botón de ejecución de la suite de
una herramienta de pruebas de código abierto llamado FitNesse que está configurada
para iDempiere el software ERP libre. Las áreas sombreadas de color muestran lo que
salió bien o y lo que no, junto con el tiempo que se tarda en ejecutar automáticamente
cada prueba en secuencia. La suite está compuesta de muchas pruebas, cada una
realizando operaciones muy detalladas paso a paso que tomarían a un humano horas
para realizar y sin error humano. Esta suite de prueba tomó 22.46 segundos para
completarse, más allá de toda la competencia humana. Haciendo nuevas pruebas de
software en mis nuevos módulos ha resultado en muchos errores encontrados.
Aún difícilmente cualquier implementador, desarrollador y usuario que conozco

involucrado en este complejo software de EPR de código abierto actualmente usa estas
herramientas para conducir pruebas después de cada cambio de código, antes de
cualquier desarrollo o copia del sistema sobre una instancia de producción en ejecución.
Algunos de mis contactos personales en el proyecto también son culpables y han sufrido
gravemente por no realizar una prueba instantánea del software desarrollado. Por
supuesto ahora cada vez que hablo con ellos están de acuerdo y asienten con la
cabeza, pero los viejos hábitos tardan en morir. Es mejor parar el resto del trabajo e ir a
probar, probar, probar el software.
Las pruebas no mienten. Son calculadas por máquinas tontas, sin duda, pero no se
desvían de lo que están programadas para hacer. Y lo hacen a velocidades increíbles.
En realidad, ahorran dinero, y desastres, como el que sucedió en
http://red1.org/BlackPaper.pdf.
Tal vez esta imagen que elijo de los cientos de gráficos y estadísticas en la Web ilustra
mejor para algunos de ustedes, el temor de lo que puede pasar antes de que ocurra.
También hay un camino equivocado para probar el software y es probar lo que hace
usted mismo. Usted no quiere probar que está equivocado la mayor parte del tiempo.
Las pruebas de software tampoco deben hacerse en el mismo equipo o en la misma
empresa. Esto es mejor realizado por una empresa o entidad profesional externa que es
medida por el número de errores que encuentran en el software. Lo sé porque lo he
aprendido al obtener el CTFL (Certificado de pruebas a nivel de fundamentos)
entrenando y pasando los exámenes hacer varios años.
Por supuesto, tener una comunidad global de código abierto nos otorga pruebas
gratuitas en todo el mundo durante todo el día. Pero los costos de pruebas de software
son 5 veces más que el desarrollo, de acuerdo con la nómina a puerta cerrada de
Microsoft de dicho personal. En Adobe, contratan a 20 probadores de software por cada
desarrollador. Las pruebas de software son una actividad permanente muy costoso y
extensa. Relegando la prueba a herramientas como FitNesse e incorporando esto
dentro de la suite Jenkins CI es el mejor camino para tomar las pruebas fuera del punto
ciego y enfoque de uno mismo hacia un enfoque disciplinado y estricto que puede
garantizar una mejor eficiencia como más adelante demostraremos.
En este docmento, debo ir a través de cada prueba, para mirar debajo de la cubierta de
su código fuente, entonces podrás entender más fácilmente y podrás modificar o
mejorar el código para compartir con la comunidad. Esto está de acuerdo con las
características de Software Libre y de Código Abierto (FLOSS) de este proyecto. Otros
que no entienden o no son capaces de leer el código podrán querer marcharse. Esto
garantiza la seguridad de mi trabajo.
Guía de referencia en línea

http://wiki.idempiere.org/en/Fitnesse.HowTo
Referencia en línea de la guía del script de prueba
http://wiki.idempiere.org/en/Fitnesse.FixtureReference
Características
Esta es la naturaleza de la guerra:
Al proteger a los demás te salvas a ti mismo
Si únicamente piensas en ti
sólo te destruirás a ti mismo
Los siete samuráis (1954)
El plugin FitNesse, es otro conjunto de trabajo increíble de Carlos Ruiz, GlobalQSS, de

Colombia, bajo el patrocinio de TrekGlobalTrekGlobal, USA. Los dos plugins se
construyen en el apilado de iDempiere y se puede ejecutar de inmediato en una
instancia de iDempiere con un mínima de trabajo. Son OSGi plugins, ellos pueden ser
instalados, iniciados y detenidos sin afectar la instancia en ejecución. Con las últimas
modificaciones introducidas por mí, incluso no afectarán la base de datos y al terminar
cada prueba la carga de trabajo no está comprometida. Así, las pruebas se pueden
ejecutar una y otra vez y con las pruebas de los cambios en los datos para los usuarios
finales para ver el efecto en una variedad de pruebas a sus sistemas y ser capaz de
analizarlos rápidamente antes del desarrollo de la instancia de producción. Los valores
de los datos de prueba y parámetros e incluso las tablas o procesos objetivo pueden ser
fácilmente cambiados por los usuarios principiantes con conocimiento técnicos o de
codificación mínimos.

Como se ha visto anteriormente la página usa estilo Wikimedia, permitiendo así a los
usuarios que están familiarizados editar el contenido de la página. Ellos pueden cambiar
el nombre de @parameter@, @SQL script, nombre *Table*, operaciones como Read,
Record, Create Record, Delete Record, Set Variable, Set Doc Action, Assert Record o Variable,
y determinar que entrada o salida debe ser. El estilo wiki también permite comentarios y
guías que pueden colocarse en la página para facilitar la lectura.
Lo que es fantástico sobre el trabajo de Carlos Ruiz es que los plugins realizan todos los
procesos y procedimientos ERP específicos en su contexto exacto requerido en el
código. Todo lo que los usuarios tienen que hacer es solo definir que quieren en la forma
de texto wiki sin ningún código de prueba extra en Java para ser escrito. Ahora puede
acceder a cualquier modelo de tabla en la base de datos, ejecutar cualquier proceso de
servidor desde el código Java, y modificar cualquier documento en la cadena de
suministro, simplemente escribiendo dentro de la wiki y presionando Prueba o Suite.
Esto es como el idioma Inglés Drools como se puede obtener.
Los diferentes bloques de texto operacional se pueden poner en una sola página si se
desea ejecutar una sola prueba. Los bloques se pueden cambiar cuando se mueve el
texto alrededor de un documento. Cada página puede ser la hija de una suite para una
sola .cadena de ejecución.
Mi mejora para la restauración (Roll Back)
Envié esta mejora aquí. http://idempiere.atlassian.net/browse/IDEMPIERE-2860.
Como se puede ver desde mi Skype con la mano grande, parece que le gusta.
Esta mejora es importante porque sin ella, cualquier prueba comprometería a la base de datos y
afectaría los planes de pruebas de datos los cuales ya son fijos y que se asumen en una base
de datos limpia. Esto requerirá constante regreso para restaurar la base de datos para ejecutar
el conjunto de prueba nuevamente. La incorporación del manipulador trxName en la mayor parte
del análisis de código también abre posibilidades futuras. También yo incorporo una etiqueta
Commit en caso de que el probador de software realmente quiera que la prueba sea en la base
de datos para una revisión más a fondo. Tome el plugin para reemplazar el servidor iDempiere
aquí: Plugin:_FitNesse_RollBack
Creación de grabación automática (Record Auto)
También he contribuido con un código
que permite la creación más rápida de
nuevos registros sin especificar los
campos y sus valores. Sólo con una línea
en blanco permitirá que el código busque
los tipos de datos correctos e ingrese
datos en la tabla en tantos campos como
sea posible. El usuario puede aún
especificar sus propios valores debajo de
la línea en blanco. Un ejemplo para crear
una orden de venta se da aquí. El otro
código permanece igual. El resultado se
muestra debajo.
Un ejemplo para la mezcla de líneas en la
orden de compra se da aquí en texto sin
formato.
|*Table* | C_Order! |
| | |
|c_doctypetarget_id | @Ref= c_doctype
[Name='Purchase Order’].c_doctype_id |
| C_Currency_ID | 100 |
| isSOTRX | N |
|*Save* | |

Manejo de la Ventana de Información (Info Window)

He hecho otro muy importante y útil método para probar Info Window que tiene procesos unidos
a ellos para procesar los registros del grupo que muestra. Al especificar la lectura de la ventana
de Información (Read Info Window), el codigo tomará la Info Window especificada, y extraerá su
secuencia SQL, y leerá su base de datos resultante para pasar al siguiente método "Run Process"
para ejecutarlo. Esto es muy útil debido al número creciente de las construcciones de
procesamiento de datos de iDempiere que están utilizando la estrategia Info Window. A
continuación se muestra un ejemplo de esto en funcionamiento mientras se prueba el módulo de
pronóstico (Forecast).
Este script muestra en su primer cuadro que accesará a la Info Window nombrada "General Sales
Forecast" en la tabla AD_InfoWindow, y accesará su AD_InfoProcess a través del siguiente cuadro
para ejecutrar GenerateBudget2SalesForecast el cual lee el resultado del primer cuadro. A
continuación se muestra el resultado.
La lectura exitosa anterior es evidente ya que devuelve la respuesta completa del proceso
prescrita por el código del proceso. Esta adición no cambia el proceso del script ejecutado y es
compatible con versiones anteriores (retrocompatible).
El único error que tuve fue que la ID de la PInstance no persiste y en consecuencia hice un
solución incremental para poder regresar el camino. Para la mayoría de los propósitos esto debe
funcionar e incluso permitir que se especifique un proceso secundario de la InfoWindow. La
lectura de la Info Window solo extrae el primer registro y por lo tanto el proceso siempre
manejará una línea del conjunto de resultados. Esto es suficiente para probar que funcionan de
acuerdo a lo establecido. El código script se da en el módulo de pronóstico (Forecast)
posteriormente.
Guía de Usuario para Desarrolladores
Como la guía wiki en línea debe ser suficiente, está guía tiene la intensión de realmente entrar
en la prueba exacta de los scripts de prueba de software o las historias de los módulos que son
llamados por los autores de FitNesse y seguir la pista exacta a los segmentos de código Java
que los manipulan. Se puede aprender mucho y ahorrar más tiempo.
Configuración para Desarrollador
Estoy usando mi configuración como desarrollador por ello durante la prueba de FitNesse, el
modo de depuración se puede utilizar para comprobar el código analizado actualmente dentro
del módulo. La contribución del trabajo original puede ser leído directamente en línea desde el
wiki realizado por Heng Sin http://wiki.idempiere.org/en/NF001_Fitnesse_Integration.
Siguiendo el tutorial para desarrolladores iDempiere (iDempier developer), yo he podido

configurar totalmente mi entorno de desarrollo integrado (IDE) de Eclipse. En un materializado
código de iDempiere pra el IDE, podrás ser capaz de encontrar los dos plugins FitNesse que ya
se encuentran disponibles dentro la pila. Durante el depurado usualmente se encuentran
establecidos en modo ocioso y necesitan ser iniciados con la consola OSGi.
Después de iniciarse deberán estar en modo activo de lo contrario FitNesse no se conectará a la

ERP. Una vez que esto está correcto, ejecute el motor FitNesse externamente en la localización
del folder "fitnesse" del código fuente ejecute el java -jar fitness.jar -p 8089 así puede ser
accesado en el puerto 8089. Al presionar el botón Suite en la parte superior izquierda mostrará
la primera pantalla de captura de este documento. A partir de aquí, mi tutorial asistirá con plena
ilustración desde este punto en adelante.
Crear una Prueba nueva

Vamos a tratar usando el Create
Record para adicionar cualquier registro
que queramos. Hagamos un nuevo
registro de usuario. Más abajo es lo que
he preparado en modo de texto sin
formato. Está claro que necesitamos
conocer las claves externas para buscar.
Puedes acceder al ejemplo de base de
datos GardenWorld rápidamente
visitando http://red1.org/DocBook y
buscando en cualquier ventana para
obtener los datos en las pestañas de las
tablas.
En primer lugar, tenemos que añadir una
nueva prueba a la suite. Haga clic en
agregar hija (Add Child) en FitNesse,
FrontPage o dentro de la suite iDempiere.
Para esta sencilla prueba, yo he elegido la suite de iDempiere. Más tarde, el capitulo del módulo
de prónostico (Forecast) tiene su propia suite con todo muy bien organizado.

Establezca el tipo de prueba. Coloque un nombre como se muestra arriba. No altere el valor del
contenido y de clic en agregar (Add).

Ahora puede dar clic en el nuevo vínculo "Create Any Record" para introducir el texto wiki. Una
forma sencilla es copiar y pegar de la página que se muestra debajo "Create Business Partner".
Como había aconsejado, yo he usado mi DocBook para encontrar los nombres de los campo, y
valores arbitrarios para pensar en ponerlos dentro.
Así que aquí está mi página de inicio en su prueba

de wiki. Vamos a darle una oportunidad.
Tenga en cuenta que he agregado una

restauración (Roll Back) por lo que la transacción
se cierra correctamente y cualquier creación no es
salvada al final dentro de la base de datos,
evitando desordenar todo.
Una vez que se da clic en salvar (save), a

continuación se muestra como se ve. Entonces
puedo probar presionando prueba (test). El cuadro
de color verde en la parte inferior *Save* confirma
que funciona. Pero nos gusta ver si realmente lo
hace. Podemos utilizar la lectura del registro (Red
Record) para comprobar. Vamos que valor
actualizado realiza el registro de usuario.
Tenga en cuenta que también podemos tener un

valor *Commit* en la restauración (Roll Back) en
caso de que se necesite un nuevo registro.
Aquí, hemos realizado con éxito una nueva página

de prueba wiki en el motor de prueba iDempiere
FitNesse. Y la prueba funciona. Vamos a añadir un
scritp de lectura para ver si la prueba también
puede hacerlo. Pero primero cuando yo reviso
ingresando (login) a iDempiere, puedo confirmar
que este registro no fue creado.
Pego el texto aquí para que puedas copiarlo y

probarlo pegándolo en tu wiki.
!include -c TestLoginGardenAdmin
!|Create Record|
|*Table* |AD_User |
|NAME |@random_string(Red1,6)|
|Value |@random_number(,,8)|
|Email |red1@red1.org|
|Password|@random_string(aaa,6)|
|Phone|@random_number(,,8)|
|*Save* | |
!|Roll Back|
|*RollBack*|TRUE|

Las opción de Restauración (Roll Back) o la opción Commit
Entonces realizó la prueba con la opción Roll Back con Commit.
Luego en el navegador de iDempiere, puedo ver que se crea un nuevo registro similar a esta
prueba.
La prueba funciona con la acción commit para rápidamente crear lo que quería.

Lectura deRegistro (Read Record)

Aquí tratamos de leer el evento virtual creado AD_User aunque no está comprometido a
comprobar que la prueba persiste únicamente durante el tiempo de ejecución.
Basta con solo mirar la gran velocidad de 0.026 segundos. Aquí vemos que no devuelve los
mismos valores por lo tanto esta prueba es un éxito rotundo. Tenga en cuenta que tenemos la
misma ID para @AD_User.AD_User_ID@ que obtiene la misma memoria durante la prueba.
Tampoco hay rastro del registro durante mi normal inicio de sesión (login) para comprobar ya
que no está en Commit. Sin embargo, esto también descubre un hoyo en la versión vanilla de
iDempier. ¡Podemos obtener la contraseña!. ¡Qué hemos atrapado!. De todos modos ahora
puede guardar la historia del fixture.

Localización del
historial Fixture
Cada vez que presione
guardar (save), su historial
fixture es guardado en el
folder FitNesse debajo del
folder FitNesseRoot donde
exactamente se tiene que
sustituir con mi folder del
mismo nombre que se
encuentra comprimido en
http://sourceforge.net/projects/red1/files/Testing/ !
Localización del código fuente

Es posible que desee saber más tarde durante el ejemplo de la suite extravaganza, de dónde
viene todo el código.
Los nombres de las clases de Java son obvios y se refieren a los títulos de los bloques de texto
wiki. Así, para crear un nuevo título simplemente se quitan los espacios a la clase Java
correspondiente. Observe como he hecho con mi nueva clase, RollBack.java.

Suite de Prueba Predefinida

Ahora vamos a ir a través de las importantes pruebas dentro de la suite creada por Carlos
Ruiz. Su trabajo es realmente asombroso y ofrece más de los ejemplos suficientes que
me han permitido aprenderlo con bastante rapidez.
Prueba rápida
El propósito de la prueba rápida es asegurarse que tu motor FitNesse está trabajando bien
además de comprobar si la base de datos está viva y respondiendo. También demuestra el uso
de Set Variable y de Read Record.
Usted puede encontrar los dos códigos fuente SetVariable.java y ReadRecord.java. de las
clases que los manejan. Las @InventoryLevelBefore@ son variables arbitrarias que se
establecen posteriormente en el script wiki para referenca del tiempo de ejecución. No están
reservadas o codificación fija (hard-coded). Este es un mecanismo poderoso que Carlos Ruiz ha
introducido para permitir la captura o paso de valores durante las pruebas.

Prueba de efectivo para orden de Punto de venta (POS)
Esta página de prueba es un ejemplo de

de una elaborada y larga prueba realizada
con muchas clases Java utilizadas para
llevar a cabo muchas tareas. En primer
lugar establece las variables para su uso
posterior. Se está probando para las
ventas de una cantidad (qty) igual a 2 y
comprobando posteriormente si el
inventario está reflejando correctamente
la orden de operación del POS. En la
siguiente lectura del registro de prueba,
se está comprobando los detalles del
socio de negocios (Business Partner).
Lo siguiente es la creación del registro

maestro de los detalles de la orden de
venta.. Observa como la configuración
DoctType o POS Order es hecha.
También nota como la clave ID de la

primer tabla maestra C_Order y la clave ID
externa de su proceso de origen es
pasada al C_OrderLine_ID. La variable
usada es @c_order_id. c_order_id@

Proceso de ejecución
(Run Process)
La siguiente tarea de prueba en la página es
Run Process el cual completará la orden de
venta del POS. Mira que simple es. El
*ProcessValue* corresponde al nombre del
registro del proceso.
Las otras variables con su pareja de valores son
parámetros para pasar al proceso del servidor.
Por último un *Run* lo arranca.
Ahora puede imaginar cualquier tipo de proceso para probar con esta simple plantilla de
trabajo.
Registro de confirmación
(Assert Record)
Esta prueba comprueba si el resultado esperado
colocado en la caja es devuelto correctamente
durante el tiempo de ejecución de la prueba. Aquí se
supone que el el gran total de la nueva orden es de
67.50. Vamos a comparar los resultado abajo
Las cajas verdes anteriores son evitadas como
hemos hecho con ellas. Aquí vemos que el proceso
de ejecución (Run Process) tiene éxito con la retroalimentación del conjunto de datos que modelo
ha regresado. Así que la retroalimentación del registro de confirmación (Assert Record) tiene un
valor similar al esperado en la configuración. Por lo tanto todo es verde y se considera correcto.

Variable de confirmación (Assert Variable)
Esta última prueba ahora toma la variable anterior y confirma esto a la SQL que extrae el total
QtyOnHand de la tabla M_Storage.
Aquí está el resultado que se muestra en la página de prueba. Sin embargo, antes de esto, la
confirmación estaba comparando el valor de la cadena y por lo tanto 28 no era igual a 28.0.
Muestro un parche para solucionarlo aquí.
https://idempiere.atlassian.net/browse/IDEMPIERE-2859
Sin embargo, Carlos Ruiz ha remarcado el ciertamente se debe evaluar el valor de la cadena, y
así he añadido un nuevo código “AssertString” estrictamente para cadenas y AssertVariable para
ambos valores alfabéticos y numéricos si se puede deducir tal situación durante la confirmación.
A continuación, el resto de la página está probando la existencia de registros generados como el

de Factura (Invoice), Pago (Payment) y Envío (Shipment). Todo esto se hace fácilmente mediante
la lectura y confirmación de los registros asociados. Esta página de prueba es un referencia muy
informativa e instructiva para cualquier otra prueba de software que deba ser configurada
rápidamente de manera que la mayoría de las operaciones quedan cubiertas con esto.

Pronóstico (Forecasting)
El pronóstico de compra es una aproximación para acortar funcionalmente la cadena de
suministro en el ERP evitando el reabastecimiento del inventario y la requisición manual.
Los pronósticos de compra son generados durante el pronóstico de venta (Sales Forecast)
e incluso ordenes de compra (Sales Order) cuando el plugin está activo. Recibirás esta
línea en el historial de la consola:
INFO: <EVENT VALIDATOR FOR SALES ORDER TO GENERATE PURCHASING FORECAST> .. IS NOW INITIALIZED!
Los pronósticos de compra son entonces procesados dentro de las

ordenes de compra actuales.
Los espacios en blanco de los pronósticos de venta pueden surgir también de los
detalles del programa de presupuesto (Budget Plan) que son los tipos de venta objetivo
para que el usuario llene los detalles (si el programa de presupuesto abstracto o
indefinido).
El módulo de pronóstico es un plugin independiente sin cambio en la tabla central y por

lo tanto no representa ningún impacto o conflicto para otra.
La ilustración de arriba muestra con el área coloreada la posición de todo el plugin, este
recorte es parte del núcleo subyacente que no invade o infringe. El módulo del programa
de presupuesto (Budget Plan), junto con el pronóstico de ventas (Sales Forecast), las
ordenes de compra (Sales Orders) y las ordenes de compra (Purchase Orders) permanecen
intactas y fuera del plugin. El plugin del presupuesto (Budget plugin) es también
actualizado para incluir la contribución de Deepak Pansheriya - http://logilite.com/budget-
journal-enhanced-budget-module/
Si hay cualquier cambio en el plugin, esto no terminar lo de afuera. Si algo de afuera

cambia esto puede terminar el plugin pero es más fácil de resolver que de la manera
inversa. El plugin es pequeño, el núcleo es enorme. Tal vez esto debería ser mi cuarto
mantra. El núcleo es enorme, tú tienes que hacer plugins.
Reutilizando el modelo de pronóstico (Forecast Model)
El pronóstico de compras reutiliza el modelo de tablas del pronóstico de ventas de M_Forecast y
M_ForecastLine con un M_ForecastProcess adicional para manejar las operaciones de compra
asociadas sin impactar el presente modelo de pronóstico fuera del módulo de manufactura
Libero donde es mantenido originalmente.
Como se ha visto anteriormente, el detalle de compra reutilizará la pestaña de línea (Line tab),
pero la pestaña del proceso (Process tab) mostrada en el fondo, indicará si se trata de un
pronóstico de compra. Un detalle de proceso en blanco significa que no es un pronóstico PO
sino solo el habitual pronóstico de venta. Si hay un detalle como ocurre en este caso, entonces
es un pronóstico PO. Usted puede ir a la pestaña "Forecast" para revisar la información de su
encabezado.
Debajo de la pestaña de línea, ya está indicado el producto (Product), cantidad (Quantity), tiempo
(Period) y fecha (Date) prometida. En la pestaña del pronóstico del proceso (Forescast Process),
almacenará el tiempo de anticipo (LeadTime) el cual es parcialmente oculto hacia el lado
derecho de la fila plazo de ejecución (LeadTime) que es calculado a partir del tiempo de entrega
(DeliveryTime) del vendedor del producto.
La pestaña del proceso de pronóstico también conserva el historial del origen del pronóstico de
compra como si, por ejemplo se tratara de una orden de venta y OrderLine, o un pronóstico de
venta y ForecastLine. En este caso se trata de un pronóstico de ventas (Sales Forecast) . (La
columna de pronóstico es bastante redundante ya que es una repetición de la pestaña principal.
Por lo tanto, se puede ocultar fácilmente utilizando la pestaña del editor [Tab Editor]. Esto se
puede quitar cuando se realice la próxima subida [upload] ).
La pestaña de pronóstico del proceso también guarda el historial junto con la ID de referencia de
la OrderLine generada, si este pronóstico PO ha sido procesado,

Estructura del Menú (Menu Structure) del pronóstico
Puedes encontrar este nuevo modelo de pronóstico en el
menú de ordenes de pronóstico (después de empaquetar el
ForecastWindow.zip o instalar el plugin
org.purchasing.forecast.jar). Aquí a la derecha, está el menú
para la planeación del presupuesto de ventas (Budget Sales
Planning). Tenga en cuenta que el último elemento en ella,
Generar Pronóstico de ventas (Generate Sales Forecast) está
asociado con el pronóstico por lo que sólo funcionará si el
plugin de pronóstico de compras (Purchasing Forecast) está
también activo. Sino el Generar Pronóstico de Ventas no es
utilizado, no es un requisito que ambos módulos deban estar
presentes al mismo tiempo.
Programación de compras (Purchasing Schedule) es una
ventana de información que revisa las ForecastLines de
compra y permite su selección para ser procesadas dentro
de las ordenes de compra (Purchase Orders).
El primer elemento, Genera Pronóstico de Compras (Generate Purchase Forecast), crea
pronósticos PO de los pronósticos de ventas. El segundo elemento, Genera Ordenes de Compra
(Generate Purchase Orders) genera POs de pronósticos PO. Esto es básicamente el propósito
principal de este módulo. Pronósticos de venta (Sales Forecasts) hacia pronósticos PO (PO
Forecasts) hacia POs.
Los POs también se consolidad de acuerdo a vendedores similares que suministran esos
elementos de los productos definidos en el pronóstico.
A continuación, en la página siguiente esta la ventana de información (Info Window) del Generar
Pronóstico de ventas (Generate Sales Forecast). Esto pasa a través de las líneas del Plan Detallado
del Presupuesto (Budget Plan Detail) para descubrir a aquellos que son los objetivos de ventas y
mostrarlos para nuevas acciones. Eso significa que aquellos que tienen el campo isSOTrx
establecito a "Y" y el campo del elemento de contabilidad (Accounting Element) vacío. Esos
detalles del presupuesto, deben ser creados por ti para asegurar que poseen valores de producto
(Product), cantidad (Qty), y tiempo (Period) para ser marcados para mostrarse en la ventana de
información.
Una vez que se seleccionan, pueden ser procesados dentro de las líneas de los pronósticos de
ventas bajo un solo encabezado de pronóstico.
Tenga en cuenta que el módulo de presupuesto, hay un configurador de presupuesto (Budget
Configurator) que se debe configurar. Puedes referirte al Budget.pdf en
http://sourceforge.net/projects/red1/files/p2/Budget/
Tenga en cuenta también que el Programa del Presupuesto de Importación (Import Budget Plan).
Puede ejecutarse el importador de archivo (File Import Loader) y cargar el BudgetTestImport.csv
(en la misma ubicación de arriba). Entonces ejecute el Programa del Presupuesto de
Importación. Pero es posible que todavía sea necesario establecer un candidato de pronóstico
de ventas haciendo un nuevo detalle sin el elemento de contabilidad (Accounting Element) y con
los valores adecuados como se indica en la primera prueba de abajo para el módulo del
pronóstico del pronóstico de venta (Purchasing Forecast module).

Ventana de Información (Info Window) del Programa de Ventas
El módulo de presupuesto está vinculado a este módulo de pronóstico permitiendo que un
subconjunto de los Detalles del Programa del Presupuesto (Budget Plan Details) que son los
objetivos de venta sean convertidos a pronósticos de ventas. A continuación se muestra la
pestaña de los Detalles de las Reglas del Programa de Presupuesto que contiene el objetivo de
las ventas debido a que los campos de contabilidad están en blanco y por lo tanto no para GL.
En la ventana de información (Info Window) del Pronóstico General de Ventas (Generate Sales
Forecast) puede mostrar este registro para la selección para procesarse en un Pronóstico de
Ventas (Sales Forecast).
Ahora será bueno para la prueba de FitNesse leer esta ventana de información, su contenido, y
activar ese botón de proceso. De hecho con mi mejora agregada lo hace. Ahora podemos leer la
ventana de información y pasar al proceso de ejecución predominante para hacer eso.

Prueba del presupuesto (Testing Budget) para prónostico de ventas
A continuación se muestra el script en bruto que permite que esto suceda. Está colocado lado a
lado con la versión mostrada del wiki de la interfase FitNesse. Tenga en cuenta la información
de pre-requisito declarada en el encabezado del wiki.
!|Read Info Window|
|*InfoWindow*|Generate Sales Forecast|
!|Run Process|
|*ProcessValue*|GenerateBudget2SalesForecast|
|*Run*||
!|Roll Back|
|*RollBack*|TRUE|
Cuando esta prueba es ejecutada, el
conjunto de datos resultante de la línea del
Programa de Presupuesto perteneciente al
objetivo de las ventas es procesado y se
muestra su éxito abajo.
El proceso devuelve otra información, por

ejemplo si cualquiera de los resultados no
tiene cantidad (qty) o no tiene cliente o
tiempo (para reunir su fecha prometida). Esto ayudará al usuario al ir después a la ventana del
modelo de pronóstico para poner esos detalles que faltan. Se pueden cambiar los datos de la
pestaña de Detalles de Reglas del Programa de Presupuesto en la página anterior para ver un
resultado diferente en la
ejecución. Esto es muy rápido
para ejecutar como puede
verse toma menos y menos
segundos en cada ejecución.
Puede añadir otro cuadro de
texto para leer el registro de
ForecastLine para comprobar
cualquiera de los resultados
actuales. Una vez más cuando
se ejecuta, sólo debe tomar
algunos milisegundos de
tiempo extra.
Tenga en cuenta que el Programa de Presupuesto de Ventas Objetivo puede estar en un nivel
alto del programa o un objetivo general el cual requiere una planificación más exacta en la etapa
de pronóstico.
Este Pronóstico de Ventas, puede entonces ser procesado como se ha mostrado anteriormente
para el Pronóstico de Compra y así sucesivamente hasta las Ordenes de Compra. Por lo tanto
este es un eslabón completo de la cadena de suministro desde la planeación presupuestaria
hasta la decisión final de compra.

Ventana de Información del
Pronóstico de Compras (Purchasing Forecast)
A continuación se muestra la ventana de información del Calendario de Compras (etiquetado
como Purchasing Forecast ) con su panel de selección de criterios para filtrar más a fondo la fila
de datos establecidos. (Los contenidos son convertidos a Pronósticos de Venta y entonces
aparecen como líneas de Pronósticos de Compra. Su actualizada base de datos (DB) no debe
mostrar esto todavía).
Siendo una ventana de información (creada por Heng Sin y entonces mejorada por mí, Anthony
Soosah, Hiep LeQ y otros) esto puede modificarse o configurarse fácilmente en el Diccionario de
la Aplicación (AD) del Sistema como se muestra en las columnas del panel de selección.
También permite una selección de las filas para ser procesadas por el botón Genera Orden de
Compra (Generate Purchase Order).
Ahora vemos nuevamente otra prueba que hace lo anterior para obtener la ventana de
información del Pronóstico de Compra y Generar la Orden de Compra. La ejecución y
resultados se muestran en la página siguiente.

Prueba de Pronóstico PO hacia PO

!|Read Info Window|
|*InfoWindow*|Purchasing Forecast|
!|Run Process|
|*ProcessValue*|InfoForecastGeneratePO|
|*Run*||
!|Roll Back|
|*RollBack*|TRUE|
Lo anterior es la historia en
bruto del script y el correcto es
el wiki guardado a partir de
esto. Una nota para los
probadores de software de
como determinar el valor del
Proceso es examinando la
pestaña del proceso
InfoWindow y copiando y
pegando el valor de la clave de
búsqueda (Search Key) como se
ha visto anteriormente, esto es
el InfoForecastGeneratePO.
Cuando se inicia la prueba, a la

derecha se muestra el resultado
en verde.

Probando Ordenes de
Venta para Pronóstico
A continuación vamos a otras
formas para crear pronósticos de
ventas. Hay una forma de Orden
de Ventas la cual se debe al
modelo del plugin o el Evento
Validador (Event Validator) que
actúa cuando se competa. Aquí
está la prueba en su totalidad.
Primero una Orden de Ventas

es realizado C_Order y
C_OrderLine, por lo que estas
dos tablas son pobladas y
procesadas respectivamente.
La C_OrderLine toma el ID de la
tabla madre de arriba, C_Order a través
de la variable
@C_Order.C_Order_ID@.
El proceso de ejecución (Run Process)

completa la orden y el registro de
confirmación (Assert Record) descubre
que ciertamente el M_ForecastProcess es
creado demostrando la existencia del
ForecastLine PO.

Probando el Modelo de
Procesamiento para el
Pronóstico
Entonces hay una forma manual a través de la
ventana de Pronóstico. Aquí hay un código para
crear un encabezado para el Pronóstico de Ventas y
línea y luego procesar todo en la DB.
Hay un script adicional para probar el cálculo del

tiempo de ejecución (lead time) el cual es
básicamente consiste en añadir números hacia atrás
de días establecidos en el Producto PO (Vendedor)
campo DeliveryTimePromised, hacia el DatePromised
en el pronóstico.
Aquí el vendedor de un producto es actualizado por

2 días.
El Producto PO es entonces leído nuevamente para
confirmar la configuración.
Aquí mi nuevo Crear Registro Automático es usado

(Create Record Auto) para definir una nueva tabla de
prueba más rápido con el detonante de una línea en
blanco. Nótese lo simple que es. Cada definición de
una tabla tiene una línea en blanco. La línea de
detalle tiene una línea adicional para definir la ID
madre. Por lo tanto mezclando con sentencias
convencionales como Crear Registro (Create Record)
es permitido y trabajar con M_ForecastLine como se
puede observar.
También tenga en cuenta que la

característica RollBack cierra la transacción
activa liberando así la conexión para evitar
la pérdida de memoria y un lento
desempeño cuando más pruebas sean
cargadas en la suite de pruebas.
Desde Generar el inicial POForecast hacia

PO, es fácil añadir una prueba más, otro
proceso de ejecución (Run Process) para
convertir el Pronóstico (Forecasts) PO
generado en tiempo de ejecución hacia
Ordenes de Compra (Purchase Orders).

Prueba del Plazo de Ejecución (Lead time) para Entrega

Continuando de la última sección, entonces leyendo nuevamente el registro permite que el
pronóstico PO sea rastreado de vuelta con precisión a través de su ID para la OrderLine final de
compra para mostrar cual es la fecha de la orden y prometido según sea requerido. Este es la
prueba más compleja en la serie para ver si todo se mantiene a través de tal actividad rigurosa.
Finalmente las pruebas se ejecutan y abajo se muestra su resultado.
Observaciones de los resultados continúan en la página siguiente. Ciertamente, esta

prueba es muy versátil, fácil de configurar sin código interfiriendo como es el caso con la
prueba JUnit. Esto ahorra mucho tiempo y me siento viento en popa cuando solo añado
el último pequeño segmento del proceso.
De hecho tras ejecutar pruebas, detecté muchos errores en mi código por no establecer
los datos mandatorios correctamente o condiciones faltantes. Después de corregir eso
en mis módulos, las pruebas confirmaron nuevamente que todo está en orden.

La tabla es actualizada
correctamente el ID del
producto = 138 (Hoe 4ft) como
se muestra y entonces se
vuelve a leer para confirmar los
2 días de plazo de ejecución
(lead time) configurados.
Puedes cambiar el tiempo de

entrega prometido y ver los
resultados en el fondo para
confirmar que el PO creado
tiene su fecha de entrega
establecida de vuelta como
corresponde.
Tenga en cuenta que las OP

son consolidadas a los
vendedores respectivos y
devuelven un mensaje de
éxito.
Con ello hemos cubierto todo el

módulo de arriba a abajo. Cada
vez que haya un cambio, basta
con ejecutar estas pruebas en
una versión de prueba para
obtener rápidamente una vista
instantánea si algo no funciona.

Prueba de la cantidad (Qty)

del Balance
Como uno de los requisitos es
también revisar la cantidad del
balance de las ordenes pendientes
donde las Ventas se sumaran a los
Pronósticos de Compra y las
Compras lo reducirán. Tales
suposiciones sobre los diferentes
modelos permite la mezcla de las
las dos pruebas en una sola para
una prueba de caja negra. En primer
lugar una prueba sencilla con una
Orden de Venta de 1 combinado con
un Pronóstico de 3 para ver el balance necesario

para ser ordenado o comprado incrementado a 4.
El plazo de Ejecución (lead time)

también permanece intacto a lo
largo del proceso.
Trata de hacerlo por ti mismo.

Ve si puedes vencer mi tiempo
de 0.951 s que me tomó esta
prueba.

Prueba del Balance

Invertido (Reversed
Balance)
Esto es bueno para probar si una
combinación de modelos
actuando sincronizadamente
harán fallar el código. Puesto
que hay dos formas de crear
Pronósticos, y dos tipos de
Ordenes, estamos intentando
ambas combinaciones juntas con
la primera antes y aquí está la
segunda de ellas donde tratamos
una Compra en el mismo tiempo
con un Pronóstico PO y
entonces ver si se reducirá de 2
en lugar de 4. La misma prueba
es fácil de reutilizar para cambiar
una orden de compra estándar
hacia una orden de compra
("Standard Order" hacia
"Purchase Order") usando el
poderoso @Ref=parser de
Carlos Ruiz sin mirar cual es la
ID del DocType exacta para
utilizar.
Aquí está el reto 0.777 s.
El resultado final en la parte

inferior muestra el balance
esperado de 2. Es decir, una
Compra de 1 artículo similar,
junto con un Pronóstico de 3 ha
resultado en 3 - 1 = 2.
La Orden final de Compra generada es por

consiguiente de dos artículos más junto con
la previa Orden de Compra de 1.!
Nuevamente, intente usted mismo para ver si

puede vencer mi record de 0.777 s.

Plazo de ejecución (lead

time) de Ventas
Directas
Esta prueba final es una repetición
de la Orden de Ventas realizada en
la prueba de Pronóstico pero con
más cosas para entretenerse.
Aquí la Orden normal de Venta de
dispara el Evento Validador para
crear un Pronóstico PO que es
eventualmente procesado dentro
del actual PO con el plazo de
ejecución de la orden tomado en
cuenta.
¡Note que tomó 0.5 s!
La lectura sucesiva de registros permite el

paso de parámetros a partir de la tabla inicial
C_OrderLine la tabla de proceso de pronóstico
(ForecastProcess) cuyo ForecastPOLine_ID ha
sido obtenido y usado para rastrear la Orden
de Compra creada, demostrando así el
correcto funcionamiento y vinculación de los
IDs de referencia de la pestaña del modelo de
Pronóstico.
Comprenda que todas estas pruebas son

progresivas para escenarios posibles de
errores ya que es más difícil encontrar el
error si muchas cosas son probadas al
mismo tiempo. Siempre se puede utilizar la
teoría de la eliminación para aislar una sola
acción que puede ser la culpable. Mezclar la
secuencia de scripts puede ayudar para
entender si un código está actuando antes o
después de la ocurrencia del error. Pero
recuerda que lo interesante y poderoso de
la solución está en el mismo código fuente
pero al menos estas pruebas te permitirán
tener un rápido para agarrarlo e identificarlo
casi instantáneamente.

Poniendo Todo Junto

El poder de FitNesse es la forma en que puede empaquetar juntas una serie de pruebas dentro de
una suite. Así que he hecho eso con el Pronóstico (Forecasting) como se muestra debajo, marcado
como Prueba del Módulo de Pronóstico (ForecastModuleTesting).
Al dar clic en la última suite te

trae a esta página y puedes
presionar el botón Suite para
ejecutar todas las pruebas.
Sin embargo es posible que
necesite quitar el Roll Back de
en medio para que tenga
tiempo para respirar. Aunque
funcionará si se ejecuta cada
uno individualmente.
El folder de la historia de esta

suite se ha subido dentro de
mi repositorio Sourceforge.
Si eres novato en el uso del

estilo Wikimedia tienes que
usar Google para averiguarlo.
Aquí en el fondo de la página
principal (FrontPage) delante
están los vínculos para
mostrarte los ejemplos de
como configurar las pruebas.
Estos scripts de prueba

pueden ser recopilados en el
folder, FitNesseRoot de mi
repositorio SourceForg en:http://sourceforge.net/projects/red1/files/Testing/. Y a continuación,
reemplace el folder iDempiere /fitness/FitNesseRoot.

Localización en Alemania (German Localisation)

Como una parte del trabajo de mi proyecto está principalmente en Alemania con el
grupo de empresas AulerSipel que han contribuido bastante a la Localización en
Alemania, también estoy recomendando un conjunto completo de pruebas para asistirlos
en su migración de iDempiere 1.0c a 2.1 o 3.0, donde estas pruebas son de suma
importancia para asegurar que las aplicaciones ERP permanecen seguras y
consistentes después de la migración. Este conjunto de pruebas es también útil para la
comunidad alemana así como la serie de plugins que ellos han desarrollado junto
conmigo también son una necesidad común allá. Estas pruebas también son útiles para
el mundo ya que hay plugins que son de utilidad global.
<en curso>

Fabricación
Tal vez esta es la parte más difícil que realmente necesita pruebas para que todo trabaje
para el módulo de fabricación Libero, yo lo he revisado personalmente algunas veces
durante aproximadamente 5 años y he descubierto algunas características incompletas
y código de interrupción (breaking code). Es un proyecto ambicioso tratar de cubrir un gran
espacio del horizonte de fabricación y distribución. Podría esto estar mejor organizado
dentro de módulos claramente separados con mejores interfaces. Otro desafío es la falta
de expertos en la materia involucrados en este proyecto o publicando un buen modelo a
seguir.
Sin embargo, las pruebas anteriores fueron capaces de asegurar ciertas partes de lo
mencionado trabajando de acuerdo a la intención para la que fueron codificados. Mi
revisión y mejora de Libero está aún en curso, para hacerla más saludable me he
involucrado en un viaje a Dinamarca para obtener datos de fabricantes de turbinas y de
carrocería de camiones. Se necesitan más pruebas completas así como pruebas de
regresión para asegurar que nada previo a esto ha sido interrumpido o roto.
Hice un ejercicio de renombramiento importante en el código del proyecto Libero,

simplemente removiendo el nombre del proyecto y los nombres de todos los vendedores
o desarrolladores por espacios de nombres (namespaces). Los derechos de autor
(Copyright) originales y la autoría se mantienen intactos al atribuirlos a Jorg Janke de
Compiere y eEvolution de México. Puedes seguir este progreso en mi foro aquí:
http://red1.org/adempiere/ viewtopic.php?f=45&t=1775&p=8691#p8691
<en curso>
(Mientras escribo esto aquí en México, tengo prevista una reunión con el creador original
de Libero y Pronóstico (Forecasting), quien me ha llamado por teléfono y me platicó sobre
su última mejora de Pronóstico. Examinaré eso y veré si este modelo se sostiene sin
impacto cruzado y donde lo necesite, lo ajustaré para aprovechar los beneficios que
contenga.)

Almacenamiento
Originalmente también dentro de Libero, pero esta vez en Muiltimage de Eslovaquia por
Norbert Bed quien ha hecho grandes mejoras a esto y ahora es una gran tarea
documentar todo su trabajo, y al mismo tiempo, configurar un buen motor de prueba.
<en curso>

Punto de Venta (POS)

El sistema POS preferido o popular bajo trabajos de integración continua para iDempiere
es a partir de una bifurcación (fork) del POS de Openbravo o Unicenta.
<en curso>

Aplicaciones Móviles
Hay un número considerable de fuertes aplicaciones móviles emergiendo tal y como
SpinSuite Android y iUIMobile.
<en curso>

F!+N3zz3 3s !D3mp!3r3 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

F!+N3zz3 3s !D3mp!3r3 PDF

Cargado por

Copyright:

Formatos disponibles

iDempiere FitNesse

Copyright (C) 2015 Redhuan D. Oon

ESTO ES UN DOCUMENTO IROSES* DE ASEGURAMIENTO DE

Traducción: Arturo Pérez

*IROSES ES UNA SOCIEDAD DE IDEAS (JOINT BRAIN-CHILD) EN

También incluye una guía operativa para introducción al nuevo

Muchos agradecimientos a Zeeshan Hasan, de SYSNOVA,

TRES LEYES DE RED1:

Los colaboradores no tienen precio

cualquier comentario o any comment or retroalimentación sobre

Page 2 of 45 Copyright (C) 2015 Redhuan D. Oon

ES MEJOR QUE CUALQUIER PETICIÓN DE ASISTENCIA SEA

Decir a alguien que ellos

Page 3 of 45 Copyright (C) 2015 Redhuan D. Oon

Guía de usuario para desarrolladores 16

Localización en Alemania (German Localisation) 41

Vamos a tratar de eso significa no más Me alegro de que esto

algo que se llama la planificación y no más tiene un nombre.

programación ágil documentación. Solo

empezar a escribir Ese fue su

código y quejarse entrenamiento.

Page 5 of 45 Copyright (C) 2015 Redhuan D. Oon

Intenta los ejemplos ahora

(A) Instala org.idempiere.fitnesse.fixture_< timestamp >.jar y

(B) Reemplaza FitNesseRoot dentro del directorio /fitnesse/FitNesseRoot

Para aprender más, sigue y pregunta en mi foro:

ESTE TRABAJO ES PATROCINADO POR

Si deseas aportar algo adicional para mí viaje y el de mi hijo de 15 años

Page 6 of 45 Copyright (C) 2015 Redhuan D. Oon

Algunas cosas sobre mí

3. Las pruebas de software comienzan con la revisión de los requerimientos y

Page 7 of 45 Copyright (C) 2015 Redhuan D. Oon

Profesor Dr. Jesús Zavala Ruiz, quien trabaja en la teoría de Auto-

Page 8 of 45 Copyright (C) 2015 Redhuan D. Oon

“Pequeñas y medianas empresas tienen grandes opciones en Odoo y

En iDempiere no tenemos nada de lo anterior y sin embargo les ganamos. No podemos

Aún difícilmente cualquier implementador, desarrollador y usuario que conozco

Guía de referencia en línea

Esta es la naturaleza de la guerra:

Al proteger a los demás te salvas a ti mismo

Los siete samuráis (1954)

El plugin FitNesse, es otro conjunto de trabajo increíble de Carlos Ruiz, GlobalQSS, de

Page 12 of 45 Copyright (C) 2015 Redhuan D. Oon

Page 14 of 45 Copyright (C) 2015 Redhuan D. Oon

Manejo de la Ventana de Información (Info Window)

Siguiendo el tutorial para desarrolladores iDempiere (iDempier developer), yo he podido

Después de iniciarse deberán estar en modo activo de lo contrario FitNesse no se conectará a la

Crear una Prueba nueva

Page 16 of 45 Copyright (C) 2015 Redhuan D. Oon

Page 17 of 45 Copyright (C) 2015 Redhuan D. Oon

Así que aquí está mi página de inicio en su prueba

Tenga en cuenta que he agregado una

Una vez que se da clic en salvar (save), a

Tenga en cuenta que también podemos tener un

Aquí, hemos realizado con éxito una nueva página

Pego el texto aquí para que puedas copiarlo y

Page 18 of 45 Copyright (C) 2015 Redhuan D. Oon

Las opción de Restauración (Roll Back) o la opción Commit

Entonces realizó la prueba con la opción Roll Back con Commit.

Page 19 of 45 Copyright (C) 2015 Redhuan D. Oon

Lectura deRegistro (Read Record)

Page 20 of 45 Copyright (C) 2015 Redhuan D. Oon

Localización del código fuente