Secret #3: Practice TDD, ATDD, and CI

Posted on October 24, 2015

I put this series together back in 2012.  Based on our experience since 2012, I’d say you don’t have to practice TDD and ATDD to use automation successfully.  Likewise, I’d tell you if you’re not using CI as part of your test strategy in 2015 you’re missing the boat.

Enjoy the original post…

This is from my series, The 5 Secrets to Automated Testing Success.

Test Driven Development was originally created by developers to ensure the code they wrote did what customers requested. It was created in the SmallTalk community and made famous by Kent Beck with his “Test Infected” junit.org site. If you want an introduction to junit and TDD, junit.org is the place to go.

Test Driven Development (or TDD) uses a very simple pattern:

• Write a Failing Test
• Make the Test Pass
• Reduce Duplication

Learn about Beaufort Fairmont’s Training CoursesNote that this pattern forces the developer to write a test before writing the code. For many people, this concept can be difficult to understand. How can you write a test case before writing the code?

This strategy is not only possible, but offers many advantages. Coders become more focused, code gets written faster, has fewer defects, actual defects are easier to find, and unit tests are not forgotten, because you can’t write any code without a failing test.

The major return from practicing TDD is that developers’ feedback loop is tightened. They gain instant feedback from everything they do in the code, and can know at all times whether they have broken the code or not.

TDD generally doesn’t cover all test cases. It covers very specific test cases within specific sub-systems or classes.

The Course

Beaufort Fairmont offers a 3-day course in TDD. This course teaches students how to practice TDD in hands-on examples. It gives students the opportunity to face real-life issues all programmers will face with TDD in a safe and coached environment. The course also encompasses mock objects and patterns for TDD. Further, students will learn about implementing TDD in Legacy codebases and techniques for doing so.

TDD for Testers

I break up testing in to 3 levels:
• Unit Tests
• Integration Tests
• E2E Tests

Unit Tests

Normally, TDD is practiced at the unit level by developers. The tests are tightly coupled to the code. This is white-box testing, where the test code has intimate knowledge of the code under test.

Integration Tests

Teams can practice TDD at the Integration Test level as well. When test teams use good tools and have the technical support they need, they can test production code before a user interface is developed.

How is that? Read the whitepaper 5-Secrets-to-Automated-Testing-Success