Sería perfectamente lógico escribir una prueba unitaria separada para la coincidencia, porque no es nada trivial.
El código que mostraste match
es un 1-liner bastante trivial sin ningún caso de borde complicado, ¿o es un ejemplo simplificado? De todos modos, supondré que está simplificado ...
Pregunta: ¿cuál es el punto de poner funciones y constantes en el espacio de nombres anónimo, si los hace inutilizables en las pruebas?
Esta pregunta es lo que quería hacerme saltar aquí, ya que Deduplicator ya mostró una forma perfectamente buena de entrar y obtener acceso a través del #include
engaño. Pero la redacción aquí hace que parezca que probar cada detalle de implementación interna de todo es una especie de objetivo final universal, cuando está lejos de serlo.
El objetivo de las pruebas unitarias uniformes no siempre es probar cada pequeña microunidad interna granular de funcionalidad. La misma pregunta se aplica a las funciones estáticas de alcance de archivo en C. Incluso puede hacer que la pregunta sea más difícil de responder preguntando por qué los desarrolladores usan pimpls
en C ++, lo que requeriría tanto friendship
y #include
trucos para la caja blanca, intercambiando la facilidad de prueba de los detalles de implementación para tiempos de compilación mejorados p.ej
Desde un punto de vista pragmático, puede sonar asqueroso, pero match
puede que no se implemente correctamente con algunos casos extremos que hacen que se dispare. Sin embargo, si la única clase externa Foo
, a la que tiene acceso match
, no puede usarla de una manera que encuentre esos casos límite, entonces es bastante irrelevante para la corrección de Foo
que match
tiene estos casos extremos que nunca se encontrarán a menos Foo
que haya cambios, en ese punto las pruebas de Foo
fallarán y lo sabremos de inmediato.
Una mentalidad más obsesiva y ansiosa por probar cada detalle de implementación interna (tal vez un software de misión crítica, por ejemplo) podría querer entrar y divertirse, pero mucha gente no necesariamente piensa que esa es la mejor idea, ya que crearía el La mayoría de las pruebas frágiles imaginables. YMMV. Pero solo quería abordar la redacción de esta pregunta que hace que parezca que este tipo de comprobabilidad de nivel de detalle interno súper fino debe ser un objetivo final, cuando incluso la mentalidad de prueba de unidad más rigurosa podría relajarse un poco aquí y evite radiografiar los elementos internos de cada clase.
Entonces, ¿por qué las personas definen funciones en espacios de nombres anónimos en C ++ o como funciones estáticas de alcance de archivo con enlaces internos en C, ocultos del mundo exterior? Y eso es todo: esconderlos del mundo exterior. Eso tiene una serie de efectos desde reducir los tiempos de compilación hasta reducir la complejidad (a lo que no se puede acceder en otro lugar no puede causar problemas en otros lugares) y así sucesivamente. Probablemente la capacidad de prueba de los detalles de implementación privados / internos no es lo más importante en la mente de las personas cuando lo hacen, por ejemplo, reduciendo los tiempos de construcción y ocultando la complejidad innecesaria del mundo exterior.
foo.cpp
, no el encabezado! OP parece entender bastante bien que no debe colocar espacios de nombres anon en un encabezado.