ios - pruebas unitarias objective c

Método privado de prueba unitaria: objetivo C

Question

Yo uso GHUnit . Quiero probar los métodos privados y no sé cómo probarlos. Encontré muchas respuestas sobre por qué o por qué no para probar métodos privados. Pero no encontré sobre cómo probarlos.

No me gustaría discutir si debo probar las partes privadas o no, sino que me centraré en cómo probarlo.

¿Alguien puede darme un ejemplo de cómo probar el método privado?

Answer 1

De acuerdo con @Lord Zsolt

También tenga en cuenta a continuación (de Desarrollo de iOS basado en prueba ISBN-10: 0-321-77418-3, ISBN-13: 978-0-321-77418-7)

Prueba de métodos privados

A menudo me han preguntado, "¿Debería probar mis métodos privados?" O la pregunta relacionada "¿Cómo debo probar mis métodos privados?" Las personas que hacen la segunda pregunta han asumido que la respuesta al primero es "Sí" y ahora están buscando para una forma de exponer las interfaces privadas de sus clases en sus suites de prueba.

Mi respuesta se basa en la observación de un hecho sutil: ya has probado tus métodos privados. Al seguir el enfoque de refactorización rojo-verde común en el desarrollo basado en pruebas, diseñó las API públicas de sus objetos para hacer el trabajo que esos objetos deben hacer. Con ese trabajo especificado por las pruebas y la ejecución continua de las pruebas que le aseguran que no ha roto nada, puede organizar las tuberías internas de sus clases como mejor le parezca. Sus métodos privados ya han sido probados porque todo lo que está haciendo es un comportamiento de refactorización para el cual ya tiene pruebas.

Nunca debe terminar en una situación en la que un método privado no se haya probado o no se haya probado por completo, ya que solo se creará cuando vea la oportunidad de limpiar la implementación de métodos públicos. Esto asegura que los métodos privados existen solo para respaldar el comportamiento público de la clase, y que deben invocarse durante la prueba porque definitivamente se invocan desde métodos públicos.

Answer 2

Los métodos en Objective-C no son realmente privados. El mensaje de error que está recibiendo es que el compilador no puede verificar que el método al que llama exista ya que no está declarado en la interfaz pública.

La forma de evitar esto es exponiendo los métodos privados en una categoría de clase, que le dice al compilador que existen los métodos.

Así que agregue algo como esto al principio de su archivo de caso de prueba:

@interface SUTClass (Testing)
- (void)somePrivateMethodInYourClass;
@end

SUTClass es el nombre real de la clase para la que está escribiendo las pruebas.

Esto hará que su método privado sea visible, y puede probarlo sin las advertencias del compilador.

Answer 3

Si un método es privado, nunca debes probarlo.

Piensa sobre esto. Debe probar el comportamiento y el contrato de sus métodos en lugar de la implementación interna

Answer 4

Un poco tarde, pero acabo de subir al tren TDD.

Los métodos privados no deberían ser probados. Debido a que usted escribe métodos privados para respaldar sus métodos públicos, al probar sus métodos públicos se evalúan indirectamente los métodos privados que los respaldan.

El principio "no se deben probar los métodos privados" está respaldado por el principio "cuando necesite probar métodos privados, probablemente signifique que debe mover esos métodos a la clase separada" , haciéndolos públicos.