domingo, 26 de junio de 2011
Log en PHP
En esta pagina se explica como crear ficheros de log para una aplicación PHP.
Resulta muy util.
Yo lo modificaria para que siguiese el patron "Singleton" de la siguiente manera:
class Logging{
private static $instance;
// define default log file
private $log_file = null;
// define file pointer
private $fp = null;
private function __construct(){
$this->log_file = 'tmp/file.log'
}
public static function getInstance(){
if (!self::$instance instanceof self){
self::$instance = new self;
}
return self::$instance;
}
// rest of source
....
}
Y en cualquier pagina php que quieras escribir:
...
Logging::getInstance()->lwrite ('Message');
...
Espero que ayude.
jueves, 16 de junio de 2011
JUnit. Una aproximación simple
Se parte de que existe un proyecto donde se quiere probar una funcion (Proyecto Eclipse):
Esta clase tiene un metodo que se desea probar:
package es.prueba;
public class ClaseQueQuieroProbar {
public int funcionQueQuieroProbar (int valor, int valor2){
return valor + valor2;
}
}
Los pasos a seguir son los siguientes:
1º Crear un proyecto de test y añadir una dependencia con el proyecto anterior:
2º Copiar las librerias de JUnit e incluirlas en el classpath del proyecto:
Ahora ya se puede empezar a programar.
3º Crear en "ProyectoDePrueba" la clase que sera la prueba del metodo:
package es.prueba.pruebas;
import es.prueba.ClaseQueQuieroProbar;
import junit.framework.Assert;
import junit.framework.TestCase;
public class SumaPrueba extends TestCase {
public SumaPrueba (String nombre){
super(nombre);
}
public void laSumaEsCorretaPrueba (){
ClaseQueQuieroProbar claseQueQuieroProbar = new ClaseQueQuieroProbar();
int resultado = claseQueQuieroProbar.funcionQueQuieroProbar(3, 2);
Assert.assertEquals(resultado, 5);
}
}
3º Crear en "ProyectoDePrueba" la clase que sera el punto de inicio de todas las pruebas:
package es.prueba.pruebas;
import junit.framework.Test;
import junit.framework.TestSuite;
public class Incio
{
public static void main (String[] args) {
junit.textui.TestRunner.run (suite());
}
public static Test suite ( ) {
TestSuite suite = new TestSuite("Pruebas");
suite.addTest(new SumaPrueba("laSumaEsCorretaPrueba"));
return suite;
}
}
Ya esta, ahora si ejecutas la clase Inicio como una aplicacion normal tendras el siguiente resultado:
.
Time: 0,015
OK (1 test)
Si hubiese fallado daria algo como lo siguiente:
.F
Time: 0
There was 1 failure:
1) laSumaEsCorretaPrueba(es.prueba.pruebas.SumaPrueba)junit.framework.junit.framework.AssertionFailedError: expected:<5> but was:<3>
at es.prueba.pruebas.SumaPrueba.laSumaEsCorretaPrueba(SumaPrueba.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at es.prueba.pruebas.Incio.main(Incio.java:10)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
Como se puede observar es muy simple y tiene muchas posibilidades:
- Poner mas pruebas en la misma clase.
- Elegir el orden en el que se ejecutan las pruebas.
- Compartir informacion entre pruebas.
- Etc...
Este ejemplo es muy simple pero JUnit tiene muchas posibilidades:
- Integracion con otros frameworks como Spring, Maven, etc..
- Uso de anotaciones.
- Etc...
Lo que te aconsejo es que cada vez que estes desarrollando y aparezca:
- Una funcion que crees que puede fallar facil por su complejidad, o por sus excesivas dependencias, etc..
- Una logica (varias funciones y varias clases) que es facil que falle.
-Etc..
Te tomes 5 minutos e incluyas una prueba en tu proyecto de pruebas. Periodicamente ejecuta las pruebas (y por supuesto antes de generar una version de tu aplicación). Te sorprenderas de la cantidad de errores "tontos" de desarrollo que se pueden eliminar asi.
Espero que os sea util. Un saludo
sábado, 4 de junio de 2011
Como plantear la division
Una vez que has seleccionado la o las tecnologías que se van a utilizar para la implementación de la aplicación se debe empezar con la fase de simulación. La fase de simulación consiste en empezar un desarrollo “de cualquier manera” y recopilar que buena práctica se esta utilizando y cual debe abandonarse. Pero sobre todo se pueden anticipar que partes se pueden modularizar.
La identificación de las partes que se pueden modularizar no solo consiste en dividir el problema adecuadamente si no en que el coste de integrar un modulo con el resto sea el minimo posible.
viernes, 3 de junio de 2011
Divide "BIEN" y venceras
Si te pones a pensar cómo desarrollar una aplicación entonces lo empiezas a plantear como la interfaz por este lado, la persistencia de datos por este otro, el acceso a periféricos por este de aquí y así sucesivamente. Al dividir en partes ganas en que simplificas el problema y en que es más fácil poder aplicar conocimientos previos a partes más pequeñas pero ganas en el gran problema de la interconexión de las partes en las que has divido la aplicación.
La definición de las interfaces entre dichas partes es básica. La definición tiene que ser clara (no dar opción a ambigüedades del tipo tu necesitas “A” y yo te envio “5”) y adaptable (para eso es básico quela interfaz ofrezca lo que se ha pedido y mas).