Una entrada interesante sobre Boost.Serialization

Me ha interesado mucho este articulo en IBM.com sobre Boost.Serialization. Basicamente esta libreria te permite convertir un objeto en un chorro de bytes (y viceversa), permitiendote enviar objetos por la red o guardarlos en un archivo. Es ideal para ayudar a un desarrollador a crear partidas salvadas y cargarlas luego, o para crear partidas en red.

El articulo es en ingles, o sea, el idioma de la informatica y de internet (yo solo lo dejo ahi... para que lo pienses.... :) )

Espero que te guste.

Apuntes de Multithreading (II)

En este segundo capitulo pretendo mostrar como se crean threads. Un thread, como expliqué en el anterior artículo, es un objeto de la clase boost::thread, asi que al crearlo se llama al constructor.

Al crearlo, como parámetro de entrada le damos una función que es la que ejecutaremos en un thread separado.

void func1()
{
    //hacer algo aqui
}
int main()
{
    boost::thread t(func1);
    t.join();
}

Aunque tambien podemos usar functors para indicar al thread que tarea ejecutar.

class complexFunc2
{
    void operator()() const
    {
        //hacer algo complejo aqui.
    }  
};

int main()
{
    boost::thread t(complexFunc2);
    t.join();
}

Hay algo que es importante. El parametro que le pasamos a un thread entra por copia y no por referencia. Una vez finaliza el thread, el objeto que le hemos pasado por copia es destruido. Esta operacion no tiene ningún peligro excepto si entre tus datos miembro tienes punteros, y el destructor los intenta borrar, asi que cuidado.

Por ejemplo:

class complexFunc3
{
    int& number;
    complexFunc3(int& _number):number(_number){}
    void operator()() const
   {
     for(int i = 0; i < 10000; i++)
       printf("%d\n",number);
   }
};
int main()
{
    int myVar = 2;
    boost::thread t(complexFunc2(myVar));
}

Una vez acaba el main, el thread principal (nuestro programa principal siempre es un thread) acaba y libera recursos. En este caso myVar es destruida. Probablemente en una de las iteraciones del bucle, printf fallará porque myVar ha dejado de existir, y por tanto number es una referencia a un número que ya no existe, y fallará.

Para evitarlo deberiamos llamar al método join(), para que el main espere la finalización de thread antes de salir. El join deberia ser llamado si al final de una funcion o dentro de la excepcion. Esto es:

int main()
{  
    int myVar = 2;
    boost::thread t(complexFunc2(myVar));

    try{
        // Algunas operaciones que pueden gnerar excepcion.
    }
    catch()
    {
        t.join();
        throw;
    }
    t.join();
}

Nos puede ser útil tambien hacer lo contrario y es separar definitivamente el thread del principal. Para ello primero debemos comprobar que hay un thread para separar, o para juntar en caso de que vayamos a usar join. Para comprobarlo usamos t.joinable(), y si sale true es que podemos hacer un detach().

int main()
{  
    boost::thread t(func);
    if(t.joinable())
        t.detach();
}

Por ultimo, explico que pasar parámetros a un thread es trivial.

void func(int i, float f){}
int main()
{  
    boost::thread t(func,2,2.5f);
    t.join();
}

Pero no hay que olvidar que los parametros se copian y que al final de la ejecución son destruidos asi que hay que tener en cuenta que enviamos y que pasará cuando sean destruidos, o que pasará cuando la función que crea el thread finalice y destruya las funciones creadas alli y el thread siga en marcha.

Pues aqui llega el final de este post, aunque todavia me queda un largo camino con los threads.

Apuntes de Multithreading

Probablemente te vas a aburrir con esta entrada, pero no pretendia ser eso sino más bien una especie de apuntes por que estoy aprendiendo desde 0 un poco de multithreading en C++.  En realidad queria escribir algo de boost::thread, pero al final se ha juntado todo un poco...

En principio habria que saber que un thread es un proceso que se ejecuta paralelamente a la aplicacion. Desde el punto de vista de Boost (aunque dentro de poco será std::thread), un thread es una clase, que podemos crear cuando queramos. Si tenemos instalado boost como libreria global a todo el sistema, no necesitamos nada para compilarlo. El código seria este:

#include "iostream"
#include  "boost/thread.hpp"

void hola()
{
    std::cout<<"Hola mundos paralelos!!!\n";
}

int main()
{
    boost::thread t(hola);
    t.join();
}

Si esto te compila y ejecuta sin quejarse es que tienes bien instalado Boost. ¿Pero funciona realmente?

Vamos a probar esto:

#include "iostream"
#include  "boost/thread.hpp"

const unsigned int MAX = 1000;
void hola()
{
    for(unsigned int i = 0; i < MAX; ++i)
    {
    	std::cout << "Mensaje dentro de la funcion HOLA numero " << i << "\n";
    }
}
int main()
{
    boost::thread t(hola);
    for(unsigned int j = 0; j < MAX; ++j)
    {
    	std::cout << "Mensaje desde el main con numero " << j << "\n";
    }
    t.join();
}

Si redireccionas la salida a un archivo, por que son 2000 lineas, tendrás que las lineas no salen separadas. Puedes encontrar lineas como esta:

Mensaje desde el main con numero Mensaje dentro de la funcion HOLA numero 13
Mensaje desde el main con numero 1014

Los carácteres entran cuando pueden, aunque pise media frase en el camino del otro thread.

Y que hace este código? Pues primero creamos un objeto thread. Como parámetro del constructor, le pasamos la función que queremos ejecutar. Luego viene el bucle que escribe mensajes en el thread principal, aunque dentro del thread tambien se estan enviando mensajes. Una vez acaba el bucle principal, si no hubiera nada más, el programa principal acabaria y el thread se quedaria alli haciendo lo que sea que tiene que hacer.

Para decir al programa que cierre el thread antes de irse, llamamos a join() que es como pedirle al programa que espere en ese punto al thread antes de continuar, y despues continue.

Y asi acaba la primera entrada sobre threads.

Creando una fuente de objetos en Unity3D

Sigo con mis experimentos en Unity. Lo que estoy intentando hacer es una fuente de objetos, es decir, que sobre un punto se vayan instanciando objetos, que irán cayendo en el suelo y desapareciendo.

Creando el terreno:

En esta parte voy a crear una especide de caja donde irán cayendo los objetos. La caja tiene cuatro paredes bajas y un suelo. Para crear el suelo voy al menú, y busco GameObject | Create Other |  Cube. Para ir rápido lo voy a situar en el (0,0,0), y lo voy a poner de unos 20x20 con una altura (en unity, por defecto la altura siempre es la 'y') de 0,2.

Luego ajustamos las paredes una a una:
Las paredes son a ojo pero con uno de grosor y 21 de ancho (en unos casos será Z y en otros X) y con una altura de 3 debería valer.

En el momento de ejecutarlo lo vas a ver muy negro asi que pongo 3 - 4 luces. Una direccional, y el resto de tipo spot, que hacer un radio de luz. Puedes experimentar, si quieres y cambiar el color, intensidad, numero de luces, etc.

Creando el Prefab.

Ahora tenemos que ver el objeto que irá creandose en la fuente. Vamos a diseñar uno. Cuando tengamos lo que queremos, haremos un prefab, que es algo asi como un modelo o molde para poder crear copias idénticas.

En mi caso voy a crear un cubo de 0.5 de lado, al que llamaré falling_box (originalidad ante todo :) ). En principio lo pondo a 5 de altura. Para que se vea claro, le pongo un material cualquiera. Voy a Materials, y elijo uno. En mi caso Fire Add. El cubo, por sí solo no va a moverse. Necesito decirle al cubo que pesa y para eso le voy a añadir un componente de Rigid body. Con el objeto seleccionado voy a component, voy a Component | Physics | RigidBody y veremos que aparece un componente RigidBody en el inspector del objeto falling_box. Si le damos al play veremos que cae, aunque cae a plomo. Le vamos a cambiar el material del que esta hecho. Para eso, vamos a los assets y seleccionamos Physics Materials. Le ponemos Bouncy en el recudro del Box Collider, en el inspector. Ahora podemos darle al play otra vez y nuestro objeto rebotará alegremente por el suelo. 

Nota: Si rotamos un poco el cubo, unos 5-45 grados cada componente, el cubo no caerá plano y botará de manera realista.

Guardamos el proyecto (File | Save Project) y preparamos nuestros deditos de programador. Vamos a hacer algunos scripts. La idea es que al cabo de un tiempo los cubos vayan desapareciendo para que no se acumulen muchos. Para ello vamos a usar un Destroyer. Le diremos que se destruya a sí mismo al cabo de 5 segundos. 

Debemos ir al panel project, crear primero un folder llamado scripts y despues un script, que en mi caso se llamará AutoDestroyer y será en C#. Cuando se crea viene con 2 funciones sin codigo, update y start. Yo le añado el código a start para que quede asi:

public class AutoDestroy : MonoBehaviour {
    
    // Use this for initialization
    void Start() {
        Destroy(gameObject, 5);
    }
}

Si lo probamos, vemos que el objeto efectivamente cae y siempre se destruye al cabo de 5 segundos. Como ya tenemos el modelo que teniamos, vamos a enlatarlo. Para ello, vamos al panel project y creamos otro folder llamado prefabs. Despues en el mismo panel project hacemos click derecho y seleccionamos un prefab, al que llamaremos FalligBouncyCube. Al principio vemos que esta blanco, que quiere decir que no tiene nada. Ahora arrastramos nuestro FallingBox al prefab, y veremos que cambia de color. 

Para probar el prefab podemos arrastrar unas cuantas veces el prefab al hierarchy o a la escena, para ver como van apareciendo cubos. Si se superponen, podemos moverlos y situarlos donde queramos.

Creando la fuente de los cubos.

La fuente de los cubos es simplemente un punto en el espacio. Se pueden crear GameObjects vacios. Lo único que tienen es una posición + rotación + escala, o sea una transformación. Lo situamos en 0,5,0. Le añadimos un script que cada segundo lance un cubo. El script seria este:

public GameObject thePrefab;
private float m_timeCounter;
private int m_objectCounter;

// Use this for initialization
void Start () {
	m_timeCounter = 0.0f;
	m_objectCounter = 0;
}

// Update is called once per frame
void Update () {
	
	m_timeCounter += Time.deltaTime;
	if(m_timeCounter > 1 && m_objectCounter < 300)
	{
		m_timeCounter = 0;
		Instantiate(thePrefab,transform.position, transform.rotation);	
		m_objectCounter++;
	}
}

Por partes. El start es un constructor. Alli inicializamos objetos. Si te fijas tenemos 3 miembros, dos privados y uno publico. El public es visible desde fuera, pero que quiere decir esto? Al arrastrar el script al objeto vacio vemos que aparece esto:
Asi que si le arrastramos el objeto FallingBouncyCube sera exactamente eso lo que cree. Cada cuanto lo creará? Cada segundo. Time.deltaTime guarda el tiempo que pasa entre cada frame, con lo que sumando tiempos conseguimos un reloj rudimentario. Para limitar el número de objetos, contamos en m_objectCounter y como maximo serán 300. Lo probamos y vemos que cada segundo cae un cubo, que tarda 5 segundos en desaparecer. Asi que solo veremos 5 cubos en pantalla.

Pero funciona!!! En un post futuro, flexibilizare todo esto que he creado para que sea mas cómodo configurarlo. Si tienes alguna duda, escribe un post!!!

Boost filesystem

Una de las librerias que siempre vienen bien conocer en boost es la filesystem. Parece una tonteria pero se pueden llegar a gastar unas cuantas horas programando y debuggando un sistema de ficheros. Si ademas es multiplataforma todavía más. Por que a los separadores de ficheros, que segun el sistema puede ser "/" o "\", se suma que en sistemas windows existen las "unidades" (C: E: D:),  que en linux existen los enlaces soft y hard...

Además de estas dificultades, que plagan nuestro código de #ifdef win32 #elseif.... , otros problemas que muchas veces nos hace acabar recurriendo al socorrido system(cmd). Con boost tenemos un codigo unificado que no desordea nuestro codigo y que nos permite interactuar con el sistema de ficheros. Podemos añadirlo con la cabecera:

#include "boost/filesystem.hpp"

Lo primero que tenemos que conocer es la clase path. La declaramos asi:

boost::filesystem::path ruta("myDir");

Otra cosa importante es que el operator/ esta sobrecargado y hace la concatenacion de directorios. Junto con la ruta declarada antes, podriamos hacer:

boost::filesystem::path ruta("myDir");
boost::filesystem::path root("myRootDir");
boost::filesystem::path completeRoot = root / ruta;
// podriamos hacer lo mismo pero ahorrando una variable con root /= ruta

Dentro de la libreria podemos encontrar algunas funciones muy útiles para borrar y crear directorios y archivos:

boost::filesystem::create_directory("dir");
boost::filesystem::remove_all("file");

E incluso para saber si existe un archivo, conocer si es un directorio, un archivo o un link

boost::filesystem::exists("file");
if(boost::filesystem::is_directory("file"))
{}

Para acabar, los iteradores nos permiten recorrer los contenidos de un determinado directorio:

boost::filesystem::directory_iterator end_iter;
boost::filesystem::directory_iterator dir_iter(directory);
for(dir_iter; dir_iter != end_iter; ++dir_iter)
{

}

En zeleste2D, esta es la funcion para crear recursivamente una ruta que no existe:

//TODO: Would this method be more general and live outside this class??
bool pathCreator( boost::filesystem::path& path_to_create )
{
 if (!fs::exists(path_to_create))
 {
     pathCreator(path_to_create.parent_path());
 }
//if not create the directory
fs::create_directory(path_to_create);
return true;

Funciones, code forwarding y slicing

Está claro que cuando declaramos una función estamos estableciendo como nos comunicaremos con el código cliente. Pero todos conocemos que en c++ existen 3 maneras diferentes de pasar parámetros: por valor, por parámetros y por referencia. Como deberíamos diseñar pues la interface de nuestras funciones? Segun la guia de estilo de google deberíamos diseñar las funciones poniendo las variables de entrada y salida como punteros y las variables de entrada como referencias constantes. Algo asi:

type1& funct(const type2& ref, type3* point){}

Salvando memoria
La primera ventaja de las referencias en las funciones y métodos va por triplicado. Por un lado es transparente para el usuario, puesto que podemos insertar las variables sin semántica de punteros y manejarlas dentro de la función de la misma forma. Además, consumimos menos memoria, puesto que solo copiamos la referencia del parametro y no copiamos el objeto. Para darnos cuenta de cuando copiamos un objeto, una manera muy buenas es usar una macro como esta:

// A macro to disallow the copy constructor and operator= functions
// This should be used in the private: declarations for a class
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
  TypeName(const TypeName&);               \
  void operator=(const TypeName&)

Después podemos declarar nuestras clases asi:

class Foo {
 public:
  Foo(int f);
  ~Foo();

 private:
  DISALLOW_COPY_AND_ASSIGN(Foo);
};

Gracias a esto, nos aseguramos que el compilador nos prohiba copiar un objeto y pare la compilación. Es una buena costumbre la de usar el compilador para protegernos de errores.

Code forwarding
La segunda ventaja viene al diseñar clases , con el code forwarding. Cuando la interface de una clase solo declara punteros a otra clase, no necesitamos la cabecera para definirlos. Esto es: si tenemos una clase asi

class Forwarded;

class Declared{

    Forwarded* m_for;

    void fund(Forwarded* f);

};

Esta clase compilaria perfectamente, puesto que Forwarded son punteros asi que el compilador no necesita conocer ningun detalle más de Forwarded para compilar. Lo unico que necesitamos es declarar la clase de manera adelantada. Es una manera de decirle al compilador: "existe una clase llamada Forwarded. Tu compila, que luego de doy mas detalles". Pero cuando le damos los detalles? Pues en el fichero de codigo, en el .cpp, es donde se hace el include.

Y que ganamos con esto? La mayoria del tiempo que tarda la compilación es en operaciones recursivas de inclusion de codigo, o sea, en parseo. Cada vez que variamos una parte del codigo de un fichero afecta a todas las cabeceras incluidas de manera recursiva en esa unidad de compilacion. Declarando el include en el fichero .cpp retiramos esta cabecera del circuito y hacemos que la compilación sea mucho mas rápida

Slicing (rebanamiento)
La tercera ventaja es que evitamos el slicing. El slicing es un problema de c++ al copiar en una variable de tipo A, una variable de tipo B que deriva A. Si tenemos las clases

class A{

public:

    int t1;

};

class B: public A{

public:

    int t2;

};

Si hacemos esto:

B b;

b.t1 = 2;

b.t2 = 3;

A a = b;

// t2 no ha sido copiado.

B b2 = a;

assert(b2.t2 == b.t2); // esto fallará

Que ha pasado? Pues que en la copia entre clases, A no tiene un miembro t2, asi que no lo copia. Cuando volvemos a copiar A en B, ese miembro ya no esta en A y por tanto es indefinido en B. Este caso es claro en el codigo anterior pero se puede hacer más dificil de ver en el paso de parametros en una funcion que acepte parametros polimorficos. Al pasar la referencia, ayudamos a prevenir esta perdida de información. Por ejemplo

B* b = new B;

b->t1 = 2;

b->t2 = 3;

A* a = b;

B* b2 = a;

assert(b2->t2 == b->t2); //OK

Boost Hash

Esta entrada va a ser muy corta, o eso espero... Boost::hash es una libreria que nos facilita el calculo del hash de cualquier entrada. Más que facilitarlo lo soluciona completamente :)

Este seria un caso muy directo:

#include "iostream"
#include "boost/functional/hash.hpp"
int main()
{
    boost::hash string_hash;
    size_t myHash = string_hash("Hola mundo");
    std::cout << "Mi hash es " << myHash << std::endl;
    return EXIT_SUCCESS;   
}

Tambien se puede lo deberiamos usar para indexar maps. Imagina que tenemos una funcion que recibe un directorio y un objeto de una clase T, y que eso lo guardamos en un std::map. Los directorios son del tipo "c:\archivos de programas\bla bla bla\jejeje\archivo". Si te fijas, cuando se empieza a comparar la función,  los 15 primeros carácteres son siempre iguales, asi que podemos perder ciclos comparando. Lo que podemos hacer es, al insertar el objeto T, calcular el hash del directorio y devolver el hash como ID. Asi nuestros accesos posteriores seran rapidisimos.

std::size_t insert( const std::string& dir, T& objeto)
{
    std::size_t hash = string_hash(dir);
    myMap[hash] = objeto;
    return hash;
}

Ahora podriamos recuperar el objeto facilmente con el ID (no controlamos los errores).

T& get(const std::size_t id)
{
   return myMap[id];
}

Nota: He incluido las cabeceras como #include "iostream" por un tema del plugin de blogger, que me formatea mal el código, pero lo puedes poner como quieras.

Boost. Ponle el turbo a C++

Encuentro que hay mucha gente que desconoce Boost Supongo que también hay mucha gente que desconoce que C++ esta a punto de cambiar de standard, y que muchas de las funcionalidades nuevas están en Boost. De ahi que muchas de las sentencias como:

boost::Thread t1;

Pasarán a ser:

std::Thread t1;

Es decir, parte del estandar. Boost ademas ahonda en la idea de algunas tecnologias que implementa el nuevo estandar, como auto_ptr que boost completa con los scoped_ptr, shared_ptr, etc.
Por otro lado, boost llena agujeros que tradicioanlmente ha tenido C/C++. Por ejemplo, C++ no tiene una libreria unificada para tranajar con el sistema de ficheros. No hay una función que nos devuelva, por ejemplo, si un fichero existe y cuanto mide, y tenemos que recurrir a librerias de terceros. Tampoco tiene una libreria de fechas unificada.
Y eso que significa? Pues que cualquier programador de c++ deberia tener instaladas las librerias boost en su ordenador, y aprender a usarlas para no tener que reinventar la rueda constantemente.

Boost para novatos:
Pues de novato a novato te voy a decir una cosa. Boost no es dificil de instalar. De hecho es muy fácil:
Las bajamos desde esta pagina. En la sección de packaged downloads nos bajamos la última versión. Lo mejor es bajar el que esta comprimido en 7z por que es el mas pequeño en windows. En linux sirve el que quieras que sea gz. Ahora lo podemos instalar. En Window necesitamos 4 sencillos pasos:

1. Crear un destino
Creamos una carpeta en nuestro ordenador donde queramos instalar las librerias de manera definitiva. Por ejemplo en c:\dev-libs\boost. (lo mejor es que la ruta no tenga espacios en blanco, por si acaso)

2. Ir al constructor de boost

Al acabar de descomprimir tendremos una carpeta de nombre boost_version (puede ser boost_1_47_0 por ejemplo). Vamos dentro de esta carperta a .\tools\build\v2. Abrimos una consola y escribimos los siguientes comandos estando en esa ruta:

bootstrap.bat
.\b2

Esperamos a que acabe todo y entonces tendremos una herramienta llamada bjam. Ahora vamos a la raiz de boost (c:\dev-libs\boost en nuestro caso) y escribimos .\tools\build\v2\bjam y entonces empieza la construccion de boost de verdad.


3. Esperar
Ir a por un café. Si estas en el curro ves a hablar con esa de marketing tan guapa... esa que tu y yo sabemos. La compilación se puede alargar un ratito dependiendo de la máquina que tengas.


4. Añadir la ruta al PATH
Ahora solo te queda añadir lo que iba en prefix + bin, en mi caso c:\dev-libs\boost\1.47\bin al path. Aunque tambien podemos instalarlo directamente en Visual Studio para no enredar con el PATH. Para ello vamos a Herramientas -> Opciones -> Proyectos y soluciones -> Directorios de VC++. 

Alli añadimos "c:\dev-libs\boost\1.47\" en "Archivos de inclusion" y "c:\dev-libs\boost\1.47\stage\lib" en "Archivos de biblioteca". Asi boost estará disponible para cualquier proyecto.

Y con eso quedaria instalado. Ahora, sin ninguna confuguracion adicional del proyecto deberiamos poder compilar algo como esto:

#include 
#include 
#include 

int main()
{
    std::string line;
    boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );

    while (std::cin)
    {
        std::getline(std::cin, line);
        boost::smatch matches;
        if (boost::regex_match(line, matches, pat))
            std::cout << matches[2] << std::endl;
    }
}

Y con eso ya tendriamos boost instalado. En general ni es tan largo ni complicado como mucha gente piensa. Espero que esto te anime a empezar. En los proximos dias escribire algunas entradas sobre librerias de boost que me parecen especialmente utiles.

Pasitos con Unity

Hace unos días me baje Unity3D para trastear un poco y la verdad es que parece un producto muy bien hecho. Lo primero que sorprende es su sencillez de ideas. Tenemos la ventana de diseño, donde vemos la escena que hemos montado, la jerarquia, que es donde montamos la escena a base de interrelacionar assets, el panel de proyecto, que es donde nuestros assets disponibles estan listos para usarse y el panel de inspeccion.

Casi todo pasa con sencillez. Queremos una luz? Buscamos en el panel de proyecto por los tipos de luces disponibles, elegimos una, la arrastramos al panel de jerarquia y en el inspector podemos cambiarle las propiedades. Casi todos los elementos estan pensados asi, con lo que ganamos en sencillez.

Unitiy no sorprende por herrmamientas 3D, o de retoque de imagen o de sonido, sino que se limitan a aconsejarte que busques alguna herramienta de verdad como Maya o Photoshop. Pero Unity3D provee metodos para recoger los productos de estas herramientas y cargarlos como assets. Tambien viene con el editor mono, para javascript o c#. Y de momento eso es lo que he visto hasta ahora. Ya ire poniendo mas entradas donde explique como me va con Unity3D

Probando tu codigo en C++ con gtest (II)

El porque de las pruebas unitarias

En la entrada anterior planteaba la necesidad de hacer test unitarios, ademas de explicar como montar la librería  compilarla y usarla. Pero quizás hay una pregunta que no respondo y es: para que? Para que una librería cuando podemos hacer programas de ejemplo?
En esta segunda entrada quiero hablar desde un punto de vista diferente y explicar que se busca con las pruebas unitarias y que estrategia tomar para sacarle partido a estas:

Imagina que estas programando y usas las STL. Al ejecutar, aparece un error muy raro. Al debugar, la excepción salta en medio del código de una de las clases que implementan std::vector. Le echaras la culpa a las STL? Las mirarás en profundidad? No. Seguro que no. Tendrás la seguridad de que lo que falla es tu código, por que sabes que las STL han sido probadas una y otra vez (y aun y así todavía tienen errores, aunque son difíciles de encontrar). Esa tranquilidad agiliza el desarrollo puesto que en caso de error siempre miramos el último código. Esa es una de las fortalezas de la reutilización de código.

Cuando pruebas su código, muchas veces haces algunas funciones de prueba pero, lo haces de una manera estructurada? Por ejemplo, esta función:

int dividir(const int a, const int b)
{
   return (a/b);
}

Como la probarías?
En principio no haríamos nada raro: un par de llamadas y ver el resultado. Con google test seria así

TEST(funcionDividirTest, dividir)
{
    EXPECT_EQ(dividir(5,2),7);
    EXPECT_EQ(dividir(5,-5),0);
}

No hay nada que hacer. Al final siempre hay bugs. En este caso, por ejemplo, no se contempla la division por cero. Si has hecho bien tu trabajo de pruebas, arreglarás el bug, y añadiras una prueba más a tu set de pruebas, y te asegurarás de que en cada compilación se ejecuten todas las pruebas. La ganancia principal aquí con las pruebas unitarias es que podemos probar nuestro código cada vez que compilamos una nueva version. En codigo más complejo, cuando probamos funciones de más alto nivel, nos permitirá descubrir cuando alguien ha metido la pata.

La vista puesta en la calidad

Resolver bugs es aburrido y una perdida de tiempo. Lo mejor es no fallar al programar. Como es casi imposible, las pruebas unitarias hacen que una vez escritas las pruebas por alli ya no fallará el programa (y si falla sera algo muy localizado). No harías ningun sacrificio por esa buena causa? Pues intenta que el código sea probable. Para hacerlo, intenta que tus funciones y métodos devuelvan algo. Si la función no debería devolver nada, pues que devuelva 0 en caso de éxito y algún valor de error en caso contrario (debidamente documentado). Evidentemente, cambiar el diseño para que sea fácilmente probable puede ser costoso pero creo que se sale ganando con creces.

Se consistente en el manejo de errores. Devuelve un código de error o haz saltar una excepción, pero no mezcles estrategias en el código.

Lleva un control de lo que has probado, pero también de lo que no has probado. Es casi más importante saber que código esta en el aire.

Desacopla tu código, por que si no las inicializaciones son pesadas y penosas. Cada subsistema debería poderse compilar por separado (siempre que sea posible). Desacoplar el código significa que cada subsistema habla con los otros subsistema a través de unas interfaces muy determinadas. Hay que evitar situaciones donde cada clases de un subsistema tiene que conocer muchas cosas de otro subsistema

Test driven development

Pero se puede hacer algo más?
Pués si. Imagina que un jefe de proyecto, manager o lo que sea te da esto:

int factorial(const int n)
{
    return 0;
}

Y además esto:

TEST(funcFactorial, aceptacion)
{
    EXPECT_EQ(factorial(0), 0);
    EXPECT_EQ(factorial(1), 1);
    EXPECT_EQ(factorial(2), 2);
    EXPECT_EQ(factorial(5), 120);
    int n = 20;
    EXPECT_EQ(factorial(n), factorial(n -1)*n);
}

Digamos que con la interface de la función yo puedo compilar, aunque siempre me devolverá 0, pero yo puedo ir haciendo otro trabajo. Tu trabajo seria programar la funcion de manera que pase el test unitario. Programala como quieras mientras no cambies la signatura de la funcion y siempre que el resultado del test sea verde.

Esta estrategia, de crear lo test antes de el codigo que bajo test, se llama test driven development. Este tipo de estrategia, aunque parezca lenta, puede llegar a reducir el tiempo de desarrollo y aumenta la calidad del codigo final, ademas de reducir el tiempo de desarrollo al haber menos fallos.