Keynote, Saturday, June 23, 14:00 – 15:30 @ B 001
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 most 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/.
Joseph Yoder is a founder and principal of The Refactory, Inc., a company focused on software architecture, design, implementation, consulting and mentoring on all facets of software development. Joseph is an international speaker and pattern author, long standing member of the ACM, and the President of The Hillside Group, a, a group dedicated to improving the quality of software development. Joseph specializes in Architecture, Analysis and Design, C#, Java, Smalltalk, Patterns, Agile Methods, Adaptable Systems, Refactoring, Reuse, and Frameworks.
Joe is the author of many patterns, including being an author of the Big Ball of Mud pattern, which illuminates many fallacies in the approach to software architecture.Joe currently resides in Urbana, Illinois. Joseph has taught, mentored, consulted, and managed various software projects for many years, including applying patterns, designing architecture, creating adaptive object models, utilizing agile methods, developing frameworks, refactoring existing systems, object oriented software development (in Java, C#/.NET, Smalltalk and C++), web development and cloud services.
Other projects involve working in both the Java and .NET environments deploying Domain-Specific Languages for clients. Joe presents tutorials and talks, arranges workshops, and organizes leading technical conferences held throughout the world, including international conferences such as Agile, Agile Portugal, Encontro Ágil in Brazil, AOSD, CBSoft, JAOO, QCon, PLoP, AsianPLoP, SugarLoafPLoP in Brazil, OOPSLA, ECOOP, SATURN, and SPLASH. Joe thinks software is still too hard to change. He wants do something about this and believes that with good patterns and by putting the ability to change software into the hands of the people with the knowledge to change it seems to be on promising avenue to solve this problem. Joe currently resides in Urbana, Illinois.