Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propogated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk we re-discover Kent's original proposition, discover where key misunderstandings occured and look at a better approach to TDD that supports sofware development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written,
A corollary to the Composition Root and Register Resolve Release patterns is that object graphs should be composed up front, sometimes well in advance to when a particular dependency is needed. Such object graphs can potentially become quite big, which tends to make some people uneasy. Isn't it terribly inefficient? No, it almost never is, and in the few cases where it is, there are ways to get around it.
This session examines big object graphs composed with and without Dependency Injection containers, using simple code examples.
Git and GitHub allow developers to work effectively together in a very flexible manner, utilizing many different workflows. But which one is the best for our project?
In this talk, I’ll explain GitHub Flow™, the way that GitHub employees (specifically on GitHub for Windows) work together. Learn how to use Pull Requests effectively - both creating them as well as managing and merging them, as well as how to document your features and review code with them.
This talk will assume basic Git knowledge and will expand on this knowledge to more advanced Git concepts in the context of GitHub.
Our most valuable tests are those that fail more often than other.
The right test is the test consciously addresses right scope, have expected time to run and easy to understand when fails.
Little over 10 years ago, we have learned and adapted test-driven development (TDD). TDD is a huge step forward to software quality, as well as to the value of your software as a company asset. Functionalities and architectures wrapped with tests can be changed under control and evolve — one of the biggest achievements in the industry during the last decade.
When codebase grows in size and complexity and dependencies start degrading team productivity, the problem of how to maintain automated test base comes to stage.
Production code changes over time due to new functionality, bug fixes, etc. – and it affects test’s code and lifetime of the tests.
If a test fails due to changes in code, it means an error has been detected early and the test has done its job.
This is point where a developer should fix a problem and a key to fix is understanding of the test, why it fails. This leads to good test design as key component of continuous integration. We cannot submit on red build and then cannot change and develop our application.
We generally want to run the whole the test suite before every code change submission and how long does it take to run - plays significant role for big projects.
if whole test suite takes more than 15 minutes, it becomes an obstacle for doing frequent changes. Teams start running not full suite or try to detect relevant tests for this particular change, etc.
Problem of redundancy in unit testing due to the large number of people is working on a project become important once test code grown in size. Developers write tests for their components, and some tests overlay each other—often covering the same code over and over again. This is not a problem from quality point of view, but maintenance can be an issue. Here we come to distinction of unit test and integration test.
The important quality metric is code coverage. There are aspects that this metric does not reflect: sensitivity to input data.
Many workflows are vitally dependent from input data: small difference in data would only add couple of lines of code to coverage, but makes huge difference in calculations and final results. However, we often do not take these effects in account when measuring quality metrics.
Our most valuable tests are those that fail more often than other. The right test is the test consciously addresses right scope, have expected time to run and easy to understand when fails.
I my talk I will be speaking about how good test design affects productivity of agile project based on large and legacy codebase. I will be focusing on lessons learned from existing project, I have been involved with, coming up with examples of good and bad test design and its consequences in project delivery. I will be giving live code examples on the go.