From the course: Cisco Certified DevNet Associate DEVASC 1.1 (200-901) Cert Prep

Test-driven development - Cisco Tutorial

From the course: Cisco Certified DevNet Associate DEVASC 1.1 (200-901) Cert Prep

Start my 1-month free trial Buy for my team

Test-driven development

“

- [Instructor] For the DevNet Associate Exam, you want to be able to describe the concepts of several different development methods. So we're going to start here with something called test-driven development. Test-driven development, or TDD for short, is one of several development methods created to help streamline the development process. As with many methods, this is initiated by either a bug or a feature request. In other words, we have some sort of requirements or goal that we're trying to achieve through our coding, as opposed to what you may traditionally think of as the development process where we write code and then we test that code out, TDD actually starts with testing, which may seem a little bit counterintuitive at first. But this actually results in shorter development cycles and better overall coding at the end. This also helps us build a set of tests that we can use at any point during our coding to check for bugs as we go through the development process. This is as opposed to trying to find and correct all of those bugs at the end of the development cycle. Also, these tests that we write and create, we can use those against other code, other software that we may be writing at a future time. These tests are what we refer to as unit tests. Unit tests are the testing that's performed against small sections or functions of code rather than the overall software, and we define units as the smallest part of software that can be tested. Our software actually contains multiple units or multiple functions that can be evaluated in this manner. With unit testing, we want to be sure we aren't creating large or complex tests. Remember, this is very focused. Before we illustrate this better with an example, let's talk about the five steps involved with test-driven development. TDD starts with testing. So the first step is to write a test. We're writing a test that will examine a very specific function of our code or a function that we want to later add into an existing code, perhaps. In other words, this is a unit test. Step two is that the test will initially fail. This test fails because, of course, we haven't written any code yet that would work. The failure of this test that gives us a target, it shows us exactly what we need to code in order to pass that test. So step three is then to actually write the code. In this step, we're only writing the snippet of code or the function that is needed to pass this unit test. We want very focused coding here rather than thinking about the overall design of the software. Step four should be that the test passes. We would continue writing and tweaking the code until we can pass the initial test that we've created. And finally, step five is what we call refactoring. In other words, we are refining and we're combining our code, and we're cleaning that up as necessary. Things we want to look out for here would be removing any hard coded variables that we might have used during testing so that the unit could be integrated with a larger software code.

Contents