XStream é a maneira mais fácil de trabalhar com XML em Java. Para trabalhar com JSON então, é ainda mais facil
XStream é a maneira mais fácil de trabalhar com XML em Java. Para trabalhar com JSON então, é ainda mais facil
Listas de x coisas só servem para lembrar de tudo o que ficou de fora, portanto, IMHO, as 10 coisas que todo o programador deveria saber são:
0 – usar o google
1 – fazer um hello world em pelo menos 5 linguagens de programação diferentes (sendo uma funcional e uma script)
2 – instalar o wordpress e tudo o que é necessario para que o mesmo execute.
3 – instalar e configurar o Ubuntu, ou outro *nix, incluindo configuração de rede e impressão
4 – entender o que é CLASSPATH
5 – saber a diferença entre HTTP e FTP, entre TCP e UDP e qual camada OSI eles atuam. bonus: saber como funciona um GET ou POST (é possivel ver usando o live http headers do firefox).
6 – conhecer o comando grep e algumas opções como -c, -v, -A
7 – SQL: entender o que é select,update,insert, delete, commit, rollback
8 – como ler e gerar XML
9 – entender o que é NULL, \0, **qqcoisa do C e quais os seus usos (principalmente em strings)
10 – a diferença entre licença BSD e GPL veja aqui.
Alem disso é bom seguir alguns blogs, frequentar foruns, listas de discussão e ler muito. Mesmo um texto “chato” como A Catedral e o Bazar traz informações relevantes e outras referencias.
Boa sorte e que começe a flame-war
Lendo sobre testes unitarios, imagine o caso onde o seu teste é complexo: um objeto que chama outro e, então, realiza as suas tarefas. Um bom caso é um DAO que acessa o banco de dados para fazer alguma coisa: se vc pensa em testar esse codigo de forma unitaria teria que subir um banco de testes e, se encontrasse um problema, poderia ser dificil dizer se é problema do DAO ou dos objetos que ele depende (como a conexão com o banco, ou o banco em si).
A solução para estes casos pode ser trabalhar com mocks: objetos “burros” que podem não ter nenhuma função alem de responder ao que vc especificou. A abordagem mais utilizada é vc programar estes objetos para responder a um ou mais metodos com argumentos especificos, assim como as respostas esperadas. No caso do DAO eu posso esperar um determinado SQL e especificar uma determinada resposta, tudo de acordo com o meu cenario de teste.
É claro que Mock Objects em excesso podem atrapalhar, mas é tudo uma questão de bom senso: costumo dizer para quem esta começando a focar os testes nas partes mais importantes do sistema, o core do modelo e regras de negocio e, então, incrementar estas praticas caso veja necessidade. Sem falar que volta e meia surge algo novo.
Para java existe o excelente framework JMock. Logo de cara o site oficial traz um exemplo de como utilizar um mock bem simples (incluindo a integração do mesmo com JUnit 4)
http://www.jmock.org/getting-started.html
Para entender, imagine esta interface
interface Subscriber { void receive(String message); }
Imagine que eu tenho um objeto do tipo Publisher que, ao invocar o metodo publish(message), ele envie esta mensagem para um Subscriber (que recebe com o metodo acima). Para testar o publish eu teria que me certificar que o metodo receive deste objeto Subscriber foi invocado com a mensagem especificada, mais ou menos assim:
import org.jmock.integration.junit4.JMock; import org.jmock.integration.junit4.JUnit4Mockery; import org.jmock.Expectations; @RunWith(JMock.class) class PublisherTest { Mockery context = new JUnit4Mockery(); @Test public void oneSubscriberReceivesAMessage() { // set up final Subscriber subscriber = context.mock(Subscriber.class); Publisher publisher = new Publisher(); // objeto que vou testar publisher.add(subscriber); // tenho que adicionar o mock! final String message = "message"; // aqui eu programo o que eu espero do teste context.checking(new Expectations() {{ oneOf (subscriber).receive(message); }}); // aqui eu executo! publisher.publish(message); } }
Facil?
Quem nunca passou por isso: ter que gerar e/ou ler arquivos xml e teve que escolher dentre diversas tecnologias e frameworks diferentes. Seja carregar tudo pra memoria ou ler aos poucos, se é um parser push ou pull, etc, é possivel dizer que para cada situação existe uma boa escolha.
Se o seu caso é trabalhar com arquivos cujos elementos podem ser mapeados em objetos java, uma boa escolha é o XStream
XStream xstream = new XStream(new DomDriver()); Person pac = new Person("Tiago", "Pac Man"); String xml = xstream.toXML(pac); /* Simples. É, para fazer o contrario, basta */ Person newPac = (Person)xstream.fromXML(xml);
Este e outros exemplos podem ser conferidos aqui:
http://xstream.codehaus.org/tutorial.html
É claro que o xml gerado assim, cru, nem sempre serve. Para isso vamos usar algumas linhas a mais para trabalhar com os recursos de alias, annotations e os Converters.
xtream.alias("pessoa",Person.class);
Dessa forma, para se livrar do nome.do.pacode.Person e trabalhar com algo mais expressivo como pessoa, basta adicionar este alias antes de converter de/para xml. Para trabalhar com aliasing de atributos (e coleções implicitas) o ponto de partida é este:
http://xstream.codehaus.org/alias-tutorial.html
É possivel trabalhar com annotations no seu modelo de classes, evitando toda essa configuração manual
http://xstream.codehaus.org/annotations-tutorial.html
Para trabalhar com o maximo de flexibilidade do XStream, entretanto, vc precisa trabalhar com Converters – Veja o exemplo da classe Birthday
http://xstream.codehaus.org/converter-tutorial.html
XStream trabalha muito bem com classes imutaveis, pois não recria os objetos usando o construtor e sim de maneira semelhante ao mecanismo de serialização de objetos, fazendo um bypass do construtor. Sem falar que traz um pensamento menos voltado a “tags” e mais OO.