Trilha da Indústria
Palestra: Pragmatic, Not Dogmatic TDD: Rethinking How We Test (slides)
One thing that has discouraged people from incorporating TDD into their organization
is the common misperceptions that tests should always be written first, before writing any production code, and, that tests and code should be developed in many tiny
increments. We believe that TDD is more about thinking carefully about how best to
validate that your software meets your requirements. Testing and validation should
drive your development process (that’s why we are fans of being Test Driven), but we
think there is so much more to testing than writing lots of unit tests.
The typical approach to TDD usually focuses on having developers write many unit tests that may or may not add value. Instead, we recommend you adopt a testing strategy that gives you the ost leverage. So, for example, rather than merely writing many unit tests, you can often get more value by defining the appropriate user-level acceptance tests. Testing should drive your development but not at the expense of every other coding and design practice). One size or one approach for testing does not fit every organization or team.
This talk challenges the “norm” for TDD. Testing should be an integral part of your daily programming practice. But you don’t always need to derive your code via many test-code-revise-retest cycles to be test-driven. Some find it more natural to outline a related set of tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, there isn’t a single best way to be Test Driven.
There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s be practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing. More discussion about Pragmatic TDD can be found here: http://adaptiveobjectmodel.com/2012/01/what-is-pragmatic-tdd/.
Tutorial: Project Retrospectives (Why, How, and When) (slides)
Retrospectives is becoming an accepted an important practice as part of the software development process. In fact, most Agile practices promote some form of regular retrospectives. At periodic times throughout any software project, team members will benefit from taking some time to examine what is going well, what is not going well, and what can be done to correct any challenges. But how does a team do this? When and how often should they be done? This tutorial will introduce techniques for conducting project retrospectives. Participants will get the opportunity to try these techniques so they can take them back to their teams.
Palestra: A importância do registro de software
A palestra abordará a importância do registro de software como forma de assegurar ao autor direitos de exclusividade na produção, no uso e na comercialização de sua criação. Para tanto, serão abordados os seguintes tópicos: (i) Legislação e Procedimentos, (ii) Imposição de direitos, (iii) Vantagens do Registro, (iv) Licença de uso e (v) Software Livre
Palestra: Da pesquisa aos Investidores: como funciona?
O objetivo desta palestra é apresentar o programa de empreendedorismo e inovação da ikewai. Será apresentado como um fundo privado de investimento esta observando as tendências na academia brasileira. Alguns casos atualmente em execução serão apresentados.
Palestra: Incubadora como Mecanismo de Desenvolvimento Regional.