O documento apresenta os conceitos e objetivos do desenvolvimento orientado a testes (TDD). O TDD é uma metodologia que propõe escrever testes unitários antes de implementar o código, seguindo os passos vermelho-verde-refatoração. O documento explica os benefícios do TDD, como código de melhor qualidade e facilidade de refatoração.
Padrões para Desenvolvimento de Software Guiado por TestesEverton Rodrigues
Este documento fornece padrões e técnicas para desenvolvimento de software guiado por testes, incluindo escrever testes primeiro, usar dados de teste realistas, e isolar testes. Os padrões ajudam a responder perguntas como quanto testar e como escolher o que testar.
Test-Driven Development - Introdução ao método de construção de software guia...Thiago Faria de Andrade
O documento resume uma palestra sobre Test Driven Development (TDD). Aborda o que é TDD, seus benefícios e padrões, como escrever testes e refatorar código mantendo os testes verdes. O objetivo é ensinar como aplicar TDD de forma efetiva para construir software de qualidade.
Aqui são apresentados as técnicas do framework JUnit
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
Este documento fornece uma introdução aos testes de unidade com a ferramenta JUnit em Java. Ele discute os objetivos e benefícios dos testes de unidade, apresenta os conceitos fundamentais do JUnit e fornece exemplos de como implementar testes com JUnit.
O documento apresenta os principais conceitos e práticas do Desenvolvimento Orientado a Testes (TDD). Resume os tópicos da agenda, incluindo introdução ao TDD, tipos de testes, exemplos práticos do processo red-green-refactor, desafios como onde começar e benefícios como design emergente e menor acoplamento.
O documento discute a importância dos testes de unidade e apresenta a ferramenta JUnit para automatizar testes de unidade. Ele também fornece boas e más práticas para escrever testes de unidade e cobre tópicos como as anotações @Test, @Before, @After e @Rule do JUnit.
Padrões para Desenvolvimento de Software Guiado por TestesEverton Rodrigues
Este documento fornece padrões e técnicas para desenvolvimento de software guiado por testes, incluindo escrever testes primeiro, usar dados de teste realistas, e isolar testes. Os padrões ajudam a responder perguntas como quanto testar e como escolher o que testar.
Test-Driven Development - Introdução ao método de construção de software guia...Thiago Faria de Andrade
O documento resume uma palestra sobre Test Driven Development (TDD). Aborda o que é TDD, seus benefícios e padrões, como escrever testes e refatorar código mantendo os testes verdes. O objetivo é ensinar como aplicar TDD de forma efetiva para construir software de qualidade.
Aqui são apresentados as técnicas do framework JUnit
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
Este documento fornece uma introdução aos testes de unidade com a ferramenta JUnit em Java. Ele discute os objetivos e benefícios dos testes de unidade, apresenta os conceitos fundamentais do JUnit e fornece exemplos de como implementar testes com JUnit.
O documento apresenta os principais conceitos e práticas do Desenvolvimento Orientado a Testes (TDD). Resume os tópicos da agenda, incluindo introdução ao TDD, tipos de testes, exemplos práticos do processo red-green-refactor, desafios como onde começar e benefícios como design emergente e menor acoplamento.
O documento discute a importância dos testes de unidade e apresenta a ferramenta JUnit para automatizar testes de unidade. Ele também fornece boas e más práticas para escrever testes de unidade e cobre tópicos como as anotações @Test, @Before, @After e @Rule do JUnit.
Este documento discute Test-Driven Development (TDD), incluindo o que é TDD, seus benefícios, como funciona na prática e desafios de implementação. Também fornece um exemplo de como usar TDD para criar uma classe pilha.
O documento descreve uma palestra sobre testes unitários em Java usando JUnit. A palestra aborda conceitos de desenvolvimento guiado por testes, como escrever testes unitários, o framework JUnit e como implementar testes em JUnit usando Eclipse.
Desenvolvimento Dirigido por Testes com JunitAdolfo Neto
O objetivo desta palestra é apresentar como funciona o desenvolvimento dirigido por testes (TDD, do termo em inglês "test-driven development"), uma técnica de projeto de software utilizada principalmente em métodos ágeis para o desenvolvimento de software. Além disso, serão mostrados exemplos práticos de como desenvolver sofwtare utilizando TDD com o auxílio do framework open source JUnit (http://junit.sourceforge.net/).
O documento descreve o framework JUnit para testes de unidade em Java. Apresenta as principais funcionalidades das versões 3 e 4 do JUnit, incluindo a migração entre elas, e cita outros frameworks para testes como J2MEUnit, SQLUnit e XMLUnit.
O documento discute técnicas e estratégias para testes de software, enfatizando a importância de: 1) testar o código sistematicamente durante o desenvolvimento, 2) verificar limites e pré-condições, e 3) automatizar testes para validação contínua e prevenção de regressões.
O documento discute os benefícios dos testes de unidade para garantir a qualidade do código e permitir refatorações seguras. Apresenta o framework JUnit para criação de testes de unidade em Java, mostrando como definir classes de teste, métodos de teste e suites de teste. Explica também os principais métodos do JUnit para validação dos resultados dos testes.
O documento resume os principais conceitos e padrões do TDD (Desenvolvimento Dirigido por Testes), incluindo: quem inventou o TDD, os benefícios, padrões como escrever testes primeiro e usar dados evidentes, como fazer testes passarem com falsificações e triangulação, e como refatorar mantendo os testes verdes.
O documento resume a trajetória profissional de Thiago Ghisi, desde sua formação inicial em 2003 até 2011, incluindo cursos, certificações e experiências de trabalho com foco em testes automatizados, programação ágil e qualidade de software.
Testes automatizados de software são essenciais para garantir a qualidade do software e evitar prejuízos. Testes manuais são difíceis, demorados e cobrem poucos casos, enquanto testes automatizados rodam rápido, cobrem muitos casos e ajudam na manutenção do código e documentação. É importante começar a automatizar testes desde o início do projeto, para garantir a testabilidade do código.
O documento fornece uma introdução sobre testes de unidade com JUnit, descrevendo: 1) o que é JUnit e suas funcionalidades; 2) os passos para criar e executar testes de unidade com JUnit; 3) como usar asserções e métodos auxiliares como setUp() e tearDown().
1) O documento apresenta um treinamento sobre testes de unidade com JUnit.
2) É abordado o desenvolvimento de software tradicional versus ágil, com foco nos testes.
3) São apresentados conceitos e práticas de Test Driven Development (TDD) usando JUnit, como escrever testes antes do código e refatorar continuamente.
O documento discute testes unitários, apresentando: 1) O que são testes unitários e seus benefícios; 2) Como escrever testes unitários usando JUnit e frameworks de mock como Mockito e PowerMock.
Refatoração refere-se à reestruturação do código-fonte de um software sem alterar seu comportamento externo, visando melhorar aspectos como legibilidade, manutenibilidade e design. O documento descreve os princípios e origens da refatoração, exemplos de técnicas como renomear variáveis e extrair métodos, além de discutir vantagens como redução de duplicação e aumento da simplicidade do código.
Introdução ao TDD (Test-Driven Development) - #guma10anosDionatan default
Introdução ao TDD (Test-Driven Development) palestrado no #guma10anos. Fazendo uma relação com o TFD (Test First Development) e Refatoração, xUnit, Baby Steps, Clean Code, Patters para TDD, Agile Testing e ATDD (Acceptance Test-Driven Development). Ao final os Coding Dojos já realizados pelo RSJUG. Ao final um Prepared Kata demonstrando o TDD na prática.
Renato Groffe tem mais de 15 anos de experiência em tecnologia e possui diversas certificações. Ele oferece serviços de consultoria em testes de software, com foco em testes unitários, e ministra treinamentos sobre o assunto. Seu portfólio inclui experiência acadêmica e projetos profissionais na área de engenharia de software e business intelligence.
Apesar de muitas empresas ainda não utilizarem técnicas de teste de software para o desenvolvimento dos seus produtos, alegando o atraso, o tempo ou o custo para esta tarefa, as pesquisas indicam que os testes ajudam na garantia de qualidade do software.
Neste artigo o autor discute conceitos relacionados a testes de unidades, como sua definição, como funcionam e como criá-los para projetos. Também aborda mitos comuns sobre testes de unidades, como seu custo e impacto na produtividade. Por fim, explica a diferença entre testes de unidades e TDD, e demonstra na prática a criação de testes de unidades para um exemplo usando o framework NUnit.
O documento discute testes de software, incluindo:
1) Testes devem ser realizados em todos os sistemas para detectar problemas
2) Benefícios dos testes incluem garantir que sistemas funcionam corretamente e melhorar qualidade
3) Deve-se testar tudo, como telas, validações e regras de negócio, para evitar erros futuros
O documento discute a técnica de desenvolvimento de software Test Driven Development (TDD). Explica que TDD envolve pequenas iterações para desenvolver novas funcionalidades, começando com testes. Aponta que TDD leva a produzir software mais robusto e desacoplado, facilitando refatoração e reduzindo erros. Também descreve princípios como escrever testes isolados e começar definindo uma lista de casos de teste.
O documento apresenta uma palestra sobre Desenvolvimento Dirigido por Testes (TDD). A palestra discute o que é TDD, como funciona, frameworks de teste de unidade, mitos sobre TDD e exemplos práticos em .NET e Java. O palestrante tem mais de cinco anos de experiência em engenharia de software e é instrutor de teste de software.
Este documento discute Test-Driven Development (TDD), incluindo o que é TDD, seus benefícios, como funciona na prática e desafios de implementação. Também fornece um exemplo de como usar TDD para criar uma classe pilha.
O documento descreve uma palestra sobre testes unitários em Java usando JUnit. A palestra aborda conceitos de desenvolvimento guiado por testes, como escrever testes unitários, o framework JUnit e como implementar testes em JUnit usando Eclipse.
Desenvolvimento Dirigido por Testes com JunitAdolfo Neto
O objetivo desta palestra é apresentar como funciona o desenvolvimento dirigido por testes (TDD, do termo em inglês "test-driven development"), uma técnica de projeto de software utilizada principalmente em métodos ágeis para o desenvolvimento de software. Além disso, serão mostrados exemplos práticos de como desenvolver sofwtare utilizando TDD com o auxílio do framework open source JUnit (http://junit.sourceforge.net/).
O documento descreve o framework JUnit para testes de unidade em Java. Apresenta as principais funcionalidades das versões 3 e 4 do JUnit, incluindo a migração entre elas, e cita outros frameworks para testes como J2MEUnit, SQLUnit e XMLUnit.
O documento discute técnicas e estratégias para testes de software, enfatizando a importância de: 1) testar o código sistematicamente durante o desenvolvimento, 2) verificar limites e pré-condições, e 3) automatizar testes para validação contínua e prevenção de regressões.
O documento discute os benefícios dos testes de unidade para garantir a qualidade do código e permitir refatorações seguras. Apresenta o framework JUnit para criação de testes de unidade em Java, mostrando como definir classes de teste, métodos de teste e suites de teste. Explica também os principais métodos do JUnit para validação dos resultados dos testes.
O documento resume os principais conceitos e padrões do TDD (Desenvolvimento Dirigido por Testes), incluindo: quem inventou o TDD, os benefícios, padrões como escrever testes primeiro e usar dados evidentes, como fazer testes passarem com falsificações e triangulação, e como refatorar mantendo os testes verdes.
O documento resume a trajetória profissional de Thiago Ghisi, desde sua formação inicial em 2003 até 2011, incluindo cursos, certificações e experiências de trabalho com foco em testes automatizados, programação ágil e qualidade de software.
Testes automatizados de software são essenciais para garantir a qualidade do software e evitar prejuízos. Testes manuais são difíceis, demorados e cobrem poucos casos, enquanto testes automatizados rodam rápido, cobrem muitos casos e ajudam na manutenção do código e documentação. É importante começar a automatizar testes desde o início do projeto, para garantir a testabilidade do código.
O documento fornece uma introdução sobre testes de unidade com JUnit, descrevendo: 1) o que é JUnit e suas funcionalidades; 2) os passos para criar e executar testes de unidade com JUnit; 3) como usar asserções e métodos auxiliares como setUp() e tearDown().
1) O documento apresenta um treinamento sobre testes de unidade com JUnit.
2) É abordado o desenvolvimento de software tradicional versus ágil, com foco nos testes.
3) São apresentados conceitos e práticas de Test Driven Development (TDD) usando JUnit, como escrever testes antes do código e refatorar continuamente.
O documento discute testes unitários, apresentando: 1) O que são testes unitários e seus benefícios; 2) Como escrever testes unitários usando JUnit e frameworks de mock como Mockito e PowerMock.
Refatoração refere-se à reestruturação do código-fonte de um software sem alterar seu comportamento externo, visando melhorar aspectos como legibilidade, manutenibilidade e design. O documento descreve os princípios e origens da refatoração, exemplos de técnicas como renomear variáveis e extrair métodos, além de discutir vantagens como redução de duplicação e aumento da simplicidade do código.
Introdução ao TDD (Test-Driven Development) - #guma10anosDionatan default
Introdução ao TDD (Test-Driven Development) palestrado no #guma10anos. Fazendo uma relação com o TFD (Test First Development) e Refatoração, xUnit, Baby Steps, Clean Code, Patters para TDD, Agile Testing e ATDD (Acceptance Test-Driven Development). Ao final os Coding Dojos já realizados pelo RSJUG. Ao final um Prepared Kata demonstrando o TDD na prática.
Renato Groffe tem mais de 15 anos de experiência em tecnologia e possui diversas certificações. Ele oferece serviços de consultoria em testes de software, com foco em testes unitários, e ministra treinamentos sobre o assunto. Seu portfólio inclui experiência acadêmica e projetos profissionais na área de engenharia de software e business intelligence.
Apesar de muitas empresas ainda não utilizarem técnicas de teste de software para o desenvolvimento dos seus produtos, alegando o atraso, o tempo ou o custo para esta tarefa, as pesquisas indicam que os testes ajudam na garantia de qualidade do software.
Neste artigo o autor discute conceitos relacionados a testes de unidades, como sua definição, como funcionam e como criá-los para projetos. Também aborda mitos comuns sobre testes de unidades, como seu custo e impacto na produtividade. Por fim, explica a diferença entre testes de unidades e TDD, e demonstra na prática a criação de testes de unidades para um exemplo usando o framework NUnit.
O documento discute testes de software, incluindo:
1) Testes devem ser realizados em todos os sistemas para detectar problemas
2) Benefícios dos testes incluem garantir que sistemas funcionam corretamente e melhorar qualidade
3) Deve-se testar tudo, como telas, validações e regras de negócio, para evitar erros futuros
O documento discute a técnica de desenvolvimento de software Test Driven Development (TDD). Explica que TDD envolve pequenas iterações para desenvolver novas funcionalidades, começando com testes. Aponta que TDD leva a produzir software mais robusto e desacoplado, facilitando refatoração e reduzindo erros. Também descreve princípios como escrever testes isolados e começar definindo uma lista de casos de teste.
O documento apresenta uma palestra sobre Desenvolvimento Dirigido por Testes (TDD). A palestra discute o que é TDD, como funciona, frameworks de teste de unidade, mitos sobre TDD e exemplos práticos em .NET e Java. O palestrante tem mais de cinco anos de experiência em engenharia de software e é instrutor de teste de software.
1 2 3 - Testando - Automatizando os testes de softwareHeider Lopes
O documento discute testes de software e desenvolvimento orientado a testes (TDD). Ele apresenta os principais tópicos: 1) razões para testar software e automatizar testes; 2) tipos de testes como unitários e de integração; 3) os princípios e benefícios do TDD; 4) um exemplo prático de implementação de testes unitários usando TDD.
O documento fornece uma introdução sobre Test Driven Development (TDD) em 3 frases:
TDD é uma metodologia de desenvolvimento de software que utiliza testes para guiar o processo de desenvolvimento de forma incremental, maximizando a qualidade do código e simplificando o processo. O framework JUnit é utilizado para automatizar a execução dos testes unitários escritos, permitindo validar o código a cada nova funcionalidade implementada. A abordagem TDD promove o refinamento contínuo do código através de sucessivas etapas de escrita de testes,
Nessa palestra relato minha experiência não como um desenvolvedor de software altamente sinistro com duzentos anos de experiência e mil livros publicados - mas sim como um "mero mortal", um desenvolvedor "de verdade", do "mundo real" aplicando a teoria que aprendeu do TDD.
Qualidade no desenvolvimento de Software com TDD e PHPUnitDomingos Teruel
O documento discute testes de software e desenvolvimento orientado a testes (TDD) usando PHPUnit. Ele introduz TDD, testes unitários, e PHPUnit, e enfatiza a importância da qualidade de software e dos testes para prevenir erros.
O documento descreve o TDD (Test Driven Development), seu ciclo e conceitos fundamentais, como escrever testes com JUnit e aplicar BDD (Behavior Driven Development). O TDD tem como objetivo código limpo e funcional através de testes automatizados, enquanto o BDD integra as regras de negócio no desenvolvimento guiado por testes.
O que seus testes garantem, o funcionamento do código ou das funcionalidades ...Isaac de Souza
A importância de testes de software já deveriam ser um consenso entre times de desenvolvimento. Contudo ainda há profissionais que não compreendem o valor deles, um dos motivos é que de fato muitos softwares possuem testes mas continuam a apresentar bugs a cada entrega. Isso ocorre porque é comum os testes garantirem o funcionamento do código, mas não das funcionalidades como um todo. Na apresentação será abordado como equilibrar testes unitários, de componentes e de integração organizando-os através de uma visão mais direcionada ao negócio, features e histórias do que apenas ao código implementado.
Test-Driven Development (TDD) utilizando o framework xUnit.netRenato Groff
Tópicos abordados:
- Motivos que contribuem para a falta de testes
- Quais os impactos da falta de testes?
- Visão geral dos diferentes tipos de testes na área de software
- Testes unitários e a plataforma .NET
- TDD: conceitos gerais
- Implementação de um exemplo prático
- Data-Driven Unit Testing
- Testes unitários e o Visual Studio 2015
O documento discute o que é teste de software, por que é necessário testar e os principais princípios e processos de teste de software. Explica que teste de software envolve executar um programa para descobrir erros, que testar é necessário para evitar prejuízos financeiros e de reputação causados por falhas, e que os humanos sempre cometem erros, justificando a necessidade de testes.
QArentena do dia 22/08/2020
Diante de todas as fases que temos que testar, uma que muitas vezes deixamos de lado é a de Unit Testing. Ela é tão importante quanto as outras que já tem a aplicação integrada. Mas o que diferencia muito com relação as outras fases é que ela tem um feedback muito rápido que ajuda muito durante a fase de desenvolvimento.
[1] O documento discute testes de unidade com o framework Junit, incluindo conceitos de testes de unidade, vantagens dos testes de unidade, como escrever testes com Junit e práticas recomendadas para testes de unidade. [2] Também aborda o uso de bibliotecas como EasyMock e DbUnit para isolar dependências e testar a camada de persistência e [3] discute o desenvolvimento guiado por testes (TDD).
Este documento apresenta um curso sobre testes automatizados, abordando testes unitários, de integração e funcionais. A unidade III discute testes de integração com ênfase em TestNG, Mockito, testes com banco de dados usando DBUnit e Seam.
Introdução à Engenharia de Testes de SoftwareCloves da Rocha
O documento discute engenharia de testes de software, incluindo: (1) a definição de teste de software como um processo para revelar falhas e melhorar a qualidade do produto final; (2) as principais atividades dos profissionais de teste; e (3) os principais tipos de testes manuais versus automatizados e ferramentas de automação.
Este documento fornece uma introdução aos testes de unidade com a ferramenta JUnit em Java. Ele discute os objetivos e benefícios dos testes de unidade, apresenta os conceitos fundamentais do JUnit e fornece exemplos de como implementar testes com JUnit.
Este documento resume um seminário sobre desenvolvimento orientado a testes (TDD) usando a biblioteca JUnit em Java. Ele descreve os princípios do TDD, apresenta JUnit como um framework de teste popular e fornece um exemplo de como usar JUnit para testar uma árvore binária.
A apresentação discute a importância dos testes de unidade e TDD, incluindo como eles melhoram o design de classes, qualidade do código e acoplamento. Também aborda níveis de teste, mock objects e quando não usar TDD.
O documento discute arquitetura evolutiva de software, definindo programação como um processo criativo de tomada de decisões, e arquitetura como um conjunto de convenções e decisões iniciais que podem facilitar ou dificultar mudanças futuras. Ele também apresenta as fases de concepção de um produto de autoatendimento, discutindo como a arquitetura deve ser definida para atender o momento do projeto e possibilitar sua evolução.
Nessa palestra será apresentado um caso real onde a Arquitetura evolutiva possibilitou que um produto inicialmente simples se tornasse uma poderosa ferramenta de integração de softwares para Service Desk. Serão apresentados os marcos do projeto, as tecnologias utilizadas, quais decisões ajudaram a manter o ritmo de evoluções e o que faríamos diferente hoje em dia.
O documento apresenta 10 lições aprendidas pelo autor ao longo do tempo sobre a academia, o mercado de trabalho, habilidades de desenvolvedores e profissionais bem-sucedidos, a importância do planejamento e da atitude, e como lidar com erros. O autor enfatiza a necessidade de aproveitar a academia, buscar equilíbrio entre tecnologia, teoria e metodologia, ter humildade, e seguir em frente mesmo quando falhar.
Denis Ferrari é um especialista em .NET que gosta de Agile e engenharia de software. Ele trabalha com informática e conserta computadores, e usa diversas ferramentas e recursos do .NET como LINQ, Common Language Runtime, e plataformas homogêneas para manipular coleções, lidar com times multilinguagem e misturar paradigmas de programação.
Desenvolvimento de software - Mercado e CarreiraDenis Ferrari
O documento apresenta Denis Ferrari, um arquiteto de software e palestrante. Ele fornece dicas sobre carreira em desenvolvimento de software, incluindo a importância de aprender inglês, técnicas como Scrum e XP, e participar de comunidades. Ele também discute suas experiências profissionais e como aproveitar ao máximo a faculdade.
Previsibilidade em desenvolvimento de softwareDenis Ferrari
O documento discute a previsibilidade no desenvolvimento de software. Afirma que projetos de software não são totalmente previsíveis devido às diferentes experiências e culturas das equipes, tecnologias utilizadas e conhecimento da área de negócio. Sugere que para realizar previsões assertivas é necessário conhecer a velocidade da própria equipe.
O documento discute Test-Driven Development (TDD) e seus benefícios. Apresenta exemplos de como escrever testes unitários em pequenos passos para garantir a qualidade do código e reduzir bugs. Também lista ferramentas como Visual Studio, NUnit que facilitam a aplicação de TDD.
O documento discute o Coding Dojo, um método de aprendizado de programação colaborativo e não competitivo. Ele enfatiza a prática de programação em pares, o aprendizado contínuo em um ambiente seguro e inclusivo, e o uso de testes para desenvolver código de alta qualidade de forma incremental.
O documento apresenta os conceitos de programação orientada a aspectos (AOP). Discute como a AOP permite separar responsabilidades transversais em aspectos, complementando a programação orientada a objetos. Também fornece detalhes sobre o autor Denis Ferrari e como entrar em contato com ele.
Em um mundo cada vez mais digital, a segurança da informação tornou-se essencial para proteger dados pessoais e empresariais contra ameaças cibernéticas. Nesta apresentação, abordaremos os principais conceitos e práticas de segurança digital, incluindo o reconhecimento de ameaças comuns, como malware e phishing, e a implementação de medidas de proteção e mitigação para vazamento de senhas.
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...Faga1939
Este artigo tem por objetivo apresentar como ocorreu a evolução do consumo e da produção de energia desde a pré-história até os tempos atuais, bem como propor o futuro da energia requerido para o mundo. Da pré-história até o século XVIII predominou o uso de fontes renováveis de energia como a madeira, o vento e a energia hidráulica. Do século XVIII até a era contemporânea, os combustíveis fósseis predominaram com o carvão e o petróleo, mas seu uso chegará ao fim provavelmente a partir do século XXI para evitar a mudança climática catastrófica global resultante de sua utilização ao emitir gases do efeito estufa responsáveis pelo aquecimento global. Com o fim da era dos combustíveis fósseis virá a era das fontes renováveis de energia quando prevalecerá a utilização da energia hidrelétrica, energia solar, energia eólica, energia das marés, energia das ondas, energia geotérmica, energia da biomassa e energia do hidrogênio. Não existem dúvidas de que as atividades humanas sobre a Terra provocam alterações no meio ambiente em que vivemos. Muitos destes impactos ambientais são provenientes da geração, manuseio e uso da energia com o uso de combustíveis fósseis. A principal razão para a existência desses impactos ambientais reside no fato de que o consumo mundial de energia primária proveniente de fontes não renováveis (petróleo, carvão, gás natural e nuclear) corresponde a aproximadamente 88% do total, cabendo apenas 12% às fontes renováveis. Independentemente das várias soluções que venham a ser adotadas para eliminar ou mitigar as causas do efeito estufa, a mais importante ação é, sem dúvidas, a adoção de medidas que contribuam para a eliminação ou redução do consumo de combustíveis fósseis na produção de energia, bem como para seu uso mais eficiente nos transportes, na indústria, na agropecuária e nas cidades (residências e comércio), haja vista que o uso e a produção de energia são responsáveis por 57% dos gases de estufa emitidos pela atividade humana. Neste sentido, é imprescindível a implantação de um sistema de energia sustentável no mundo. Em um sistema de energia sustentável, a matriz energética mundial só deveria contar com fontes de energia limpa e renováveis (hidroelétrica, solar, eólica, hidrogênio, geotérmica, das marés, das ondas e biomassa), não devendo contar, portanto, com o uso dos combustíveis fósseis (petróleo, carvão e gás natural).
Este certificado confirma que Gabriel de Mattos Faustino concluiu com sucesso um curso de 42 horas de Gestão Estratégica de TI - ITIL na Escola Virtual entre 19 de fevereiro de 2014 a 20 de fevereiro de 2014.
As classes de modelagem podem ser comparadas a moldes ou
formas que definem as características e os comportamentos dos
objetos criados a partir delas. Vale traçar um paralelo com o projeto de
um automóvel. Os engenheiros definem as medidas, a quantidade de
portas, a potência do motor, a localização do estepe, dentre outras
descrições necessárias para a fabricação de um veículo
2. SobreDenis Ferrari GraduandoemSistemas de informaçãopelaFAESA; Arquiteto de software; Ministrapalestras e treinamentos; Consultor de negócios; MCP, MCTS (Web Applications e Distributed Applications), MCPD (Web Applications); EscreveartigosparaosportaisImasters, Linha de código e osdisponibilizatambémemseu blog. 9 anos de experiência no mercado de TI capixabaatuandocomoInstrutor, Web Master, DesenvolvedorSênior e Gerente de Projetos;
3. Objetivosdapalestra Apresentar a metodologiaágile seusvalores. Apresentar o desenvolvimentoorientado a testescomoumaalternativaaodesenvolvimentotradicional.
5. MetodologiaÁgil Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software. http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
6. Histórico Começou em um encontro em Fevereiro de 2001, Utah, USA. com os seguintes representantes: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-DrivenDevelopment, Pragmatic Programming, e outros; O objetivo do encontro foi discutir alternativas ao rigoroso processo de documentação necessário para o processo de desenvolvimento de software; Deu origem ao "Manifesto Ágil" assinado pelos dezessete participantes do encontro.
7. Conceitos DEFINIÇÃO:Movimento iniciado por programadores experientes e consultoresem desenvolvimento de software. PRINCÍPIOS:Indivíduos e interações X processos e ferramentas;Software funcional X documentação abrangente;Colaboração com o cliente X negociação de contratos;Adaptação a mudanças X seguir plano inicial. http://agilemanifesto.org/
8. Assinaram o manifesto: Kent Beck, Mike Beedle, Arie van Bennekum, AlistairCockburn,WardCunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Roland Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland; Dave Thomas.
10. TDD é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, começando pela implementação de um caso de teste, depois pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código visando melhor acomodar as mudanças feitas. Não é um método para testar software, mas para construir software. TDD vem do conceito de “test-first programming” do XP (Extreme Programming), mas acabou ganhando tanto interesse, que hoje tem sido adotado independente do XP e das técnicas de programação ágil; Introdução ao TDD (1/2)
11. Objetivo do TDD: código limpo que funciona “Mantra” do TDD: vermelho-verde-refatorar Codifique o teste; Faça ele compilar e executar (não deve passar - vermelho); Implemente o requisito e faça o teste passar (verde); Refatore o código; Introdução ao TDD (2/2)
12. Garante a existência de testes unitários completos e atualizados, que: Eliminam o medo de alterarmos alguma coisa que funciona (testada manualmente), e acabarmos introduzindo algum problema; Nos permite utilizar refatoração (substituir uma implementação por outra equivalente) de forma muito mais agressiva devido à facilidade dos testes verificarem o resultado. Diminui a quantidade de erros por linha de código (código-fonte de mais qualidade) Testes unitários servem como especificação de como os componentes do sistema funcionam; Nos leva a produzir componentes de software mais desacoplados, para garantir o isolamento dos testes, o que acaba favorecendo o projeto do sistema. Principais Benefícios do TDD
13. Testes de Unidade; Testes de Integração; Testes de Sistema; Testes de Integração de Sistema; Testes de Aceitação; Tipos de Testes
14. A Metodologia TDD é conduzida através dos “testes do programador”. Frequentemente esses testes são chamados de “teste de unidade”, mas esse nem sempre é o caso (pode ser teste de integração). É importante destacar que não se trata dos testes de sistema (caixa preta) nem os de aceitação (feitos pelo usuário final) Tipos de Testes
15. A “Espiral da Morte” do Teste O ciclo mortal do “estou sem tempo para testar”:
16. 1. Construa testes isolados uns dos outros Um caso de teste não deve depender do sucesso de outro para funcionar; Deve ser possível executar um caso de testes isoladamente, sem executar nenhum outro; 2. Comece definindo uma “TestList” De modo geral para uma mesma classe ou método a ser testado, existirão diferentes casos de teste. Liste-os primeiro (brain-storm); Provavelmente ao longo do desenvolvimento você adicionará novos casos de teste à lista; Princípios
17. Mas o que testamos? Fluxos Condicionais (IFs, Switches, etc.) Polimorfismos Loops Operações Etc.. Princípios
18. Exemplo de “Lista de Testes” para o caso de uso “Realizar Transferência Bancária”: Realizar uma transferência normal (bem sucedida); Tentar transferir uma quantidade superior ao saldo da conta de origem; Verificar atomicidade no caso de falha de sistema antes de concluir a operação; Conta de origem inativa; Conta de destino inativa; Valor transferido menor que zero; Princípios
19. Exemplo de “Lista de Testes” para o caso de uso “Matricular Aluno em Disciplina”: Matricular com sucesso; Tentar matricular sem atender disciplinas pré-requisito; Tentar matricular sem atender pré-requisito de crédito; Tentar matricular com conflito de horário; Tentar matricular sem vaga; Tentar matricular em disciplina já cumprida; Tentar matricular em disciplina que já está matriculada (outra turma); Tentar matricular em disciplina que já está matriculada (mesma turma); Princípios
20. 3. Primeiro o Teste Oportunidade para pensar no design (projeto) das classes Controlar o escopo do que será implementado – somente o necessário para atender o teste corrente. 4. Primeiro a Assertiva É melhor pensarmos no que significa o sucesso do caso de teste antes de pensarmos no restante: Vou precisar de criar um novo método? Em qual classe? Qual será o nome dele e seus parâmetros? “Primeiro a assertiva” está para o caso de teste assim como “Primeiro o teste” está para o caso de uso; Princípios
22. 5. Dados para Teste Não escolha números mágicos se eles não tiverem um significado específico no teste. Por exemplo, se não faz diferença utilizar “1”, “2” ou “1365”, preferia “1”. Evite passar o mesmo valor para diferentes parâmetros. Por exemplo, para testar um método Operacao(int x, int y), não utilize Operacao(2,2), pois “Operacao” pode inverter “x” e “y” e o teste ainda assim passar. Prefira, por exemplo, Operacao(2,3). Dê preferência a dados do mundo real, especialmente quando você tem algum sistema legado com dados que podem ser aproveitados Princípios
23. 6. Dados com Significado Evidente Lembre que está escrevendo um teste para alguém ler, e não somente para ser executado pelo computador. Tente escrever na assertiva expressões que não só representem o valor final esperado, mas o que eles significam. Exemplo: Princípios [Test] publicvoid Testar_Fatorial_8() { Assert.AreEqual(40320, Matematica.Fatorial(8)); } [Test] publicvoid Testar_Fatorial_8() { Assert.AreEqual(8 * 7 * 6 * 5 * 4 * 3 * 2, Matematica.Fatorial(8)); }
24. Trata sobre quando escrever, onde escrever e quando parar de escrever testes. Qual o próximo teste da lista a implementar? Escolha um teste que você esteja confiante que pode implementá-lo facilmente; Não comece pelo teste mais realístico (completo), pois você será forçado a implementar um monte de coisas para atender o teste. Siga na direção “mais conhecidos” para “pouco conhecidos” Cada iteração “red/green/refactor” deve levar apenas alguns minutos. Exercício: Se você estiver construindo uma lista encadeada, qual seria seu primeiro caso de teste? “Red Bar Patterns”
25. Testes de Estudo Devemos escrever testes para componentes ou bibliotecas de terceiros que, supostamente, funcionam? Sim. Para estudar e documentar seu uso. Esse é uma forma de assegurar-se sobre como utilizar tal biblioteca de forma a obter os resultados esperados e documentar seu uso (considerando especificamente suas necessidades, e não todos os recursos da biblioteca). “Red Bar Patterns”
26. Testes de Outras Funcionalidades Sempre que uma discussão desviar do assunto principal e entrar em outras questões, essa pode ser uma hora de adicionar novos casos de teste à sua lista (para a funcionalidade em questão) e voltar para o assunto principal. “Red Bar Patterns”
27. Defeitos Reportados Sempre que um defeito é reportado nossa primeira ação deve ser escrever um caso de teste que reproduza o problema. Se isso for feito certamente o problema será resolvido. Testes de Regressão Consiste em testar novamente uma funcionalidade que foi implementada e testada anteriormente; Teoricamente, após qualquer alteração no sistema, todo o sistema deveria ser testado para garantir que essa alteração não tenha introduzido algum efeito colateral indesejável. Uma boa prática é executar testes de regressão de todo o sistema, todos os dias, à noite, e reportar os problemas encontrados para a equipe. Existem softwares para gerenciar isso. “Red Bar Patterns”
28. Técnicas mais detalhadas sobre como escrever testes. Subdividir Testes Quando um teste ficou grande demais e você está demorando muito para conseguir implementá-lo (mais de 10 min já deve te encomodar), pode ser melhor dividir o teste em testes menores até conseguir fazer o teste maior passar. MockObjects Como testar objetos que dependem de recursos externos custosos ou complexos, como bancos de dados e webservices, por exemplo? Crie uma versão falsa ou simulada do objeto (“fake”) que retorne valores constantes. Referência: www.mockobjects.com Ferramentas para .NET: NMock e RhinoMocks. “TestingPatterns”
29. Uma vez que você tenha um teste vermelho, busque torná-lo verde o quanto antes. Use os padrões que serão discutidos para conseguir isso rapidamente, mesmo que o resultado seja algo que você não aceita conviver nem por uma hora. “Green Bar Patterns”
30. “Fake it ‘til youmake it” (simule até construir realmente) Por exemplo, qual é a forma mais simples de implementar o código abaixo? A forma mas direta seria: “Green Bar Patterns” publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); } publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); } publicint Somar(int x, int y) { return 5; }
31. Triangulação Quando você tem dois ou mais testes, você precisa de uma implementação que atenda a todos simultaneamente. Agora a solução trivial (constante) não atende mais, e somos forçados e implementar algo mais abrangente. É claro que esse exemplo é apenas ilustrativo. Se você já tem uma implementação correta óbvia, então implemente. Senão, “fake it”. “Green Bar Patterns” Página 31 publicvoidTestarSoma() { Assert.AreEqual(5, Somar(2,3)); Assert.AreEqual(7, Somar(3,4)); }
32. Implementação Óbvia Se você consegue implementar algo diretamente, então implemente. Para que utilizar “fake” ou triangulação? Mas quando você achar que sabe implementar e se deparar com uma barra vermelha? Depois você descobre, errei aqui, e aí outra barra vermelha! Talvez seja hora de dividir o problema em problemas menores. Acreditar que você sempre vai conseguir acertar e escrever o código mais simples para o problema diretamente é exigir de você perfeição. “TestingPatterns”