From the course: Cisco DevNet Associate (200-901) Cert Prep 1: Software Development and Design
Learn about test-driven development (TDD)
From the course: Cisco DevNet Associate (200-901) Cert Prep 1: Software Development and Design
Learn about test-driven development (TDD)
- [Instructor] Let's talk about a widely adopted software development process called test-driven development. Test-driven development or TDD at its core is a software development process that relies on writing small tests first, then write the code to conform to that test. American software engineer, Kent Beck is often credited with developing this test first development technique. In TDD each new feature begins with writing a test. Why do we write the test first? Doesn't it make sense to just write code? If we think about it, to write a small test against a new feature, the developer must fully understand the features, specifications, requirements, exception conditions, user expectation, use cases, and potentially how this new feature would fit into the overall user story. So writing a test requires the developer to understand the feature in depth. The developer will then run all the existing tests if any, and the new test to make sure the new test fail. This might sound redundant at first, after all why would the new test pass if the code has not even be written yet? The idea is actually to break the test down into small pieces and test both the positive and negative scenarios. In this case, it's a negative scenario. Seeing the test fail we're insured that the test works properly to test against the new feature at hand. The next step is to write the code to make sure the test passes. It is susceptible at this point that the code might not be perfect or fast, but the objective in this step is to pass the test. After the test passes, we will come back to the code, improve their code, run the test again, and basically rinse and repeat the process until the code is mature. So, why do we want to use TDD? At this point, you might be thinking test-driven development is just so tedious. Why can't we just write the code as quickly as possible and call it a day? I can certainly understand where that thinking is coming from. So let's take a moment to think about some of the advantages of test-driven development. The first reason is that by using TDD, as we have discussed, it forces the developer to truly understand the new feature he or she is trying to implement and think about the customer facing outcome first. After all, the developer really needs to understand the requirements, expectations, user stories and air conditions in order to write the test. The second reason is that TDD often results in cleaner code. By focusing on writing just enough code to pass the test, the principle of Keeping It Simple, Stupid (KISS) can be deployed. The third reason is the shorter development cycle that TDD helps to facilitate, how so? Even though we might be introducing extra steps of testing, by spending more time focusing on the feature upfront, the overall development cycle is generally reduced. The fourth benefit is that because we're constantly running tests, we could discover bugs and errors more quickly. Remember, when we run our tests we're running all the test cases. So if our new code inadvertently breaks some other features, we could discover it really fast. Other advantages include self documentation, improved code readability, less debugging time, consistent code structure, and many others. So let's take a look at an example of test-driven development.
Practice while you learn with exercise files
Download the files the instructor uses to teach the course. Follow along and learn by watching, listening and practicing.
Download courses and learn on the go
Watch courses on your mobile device without an internet connection. Download courses using your iOS or Android LinkedIn Learning app.