Book Image

Practical Test-Driven Development using C# 7

By : John Callaway, Clayton Hunt
Book Image

Practical Test-Driven Development using C# 7

By: John Callaway, Clayton Hunt

Overview of this book

Test-Driven Development (TDD) is a methodology that helps you to write as little as code as possible to satisfy software requirements, and ensures that what you've written does what it's supposed to do. If you're looking for a practical resource on Test-Driven Development this is the book for you. You've found a practical end-to-end guide that will help you implement Test-Driven Techniques for your software development projects. You will learn from industry standard patterns and practices, and shift from a conventional approach to a modern and efficient software testing approach in C# and JavaScript. This book starts with the basics of TDD and the components of a simple unit test. Then we look at setting up the testing framework so that you can easily run your tests in your development environment. You will then see the importance of defining and testing boundaries, abstracting away third-party code (including the .NET Framework), and working with different types of test double such as spies, mocks, and fakes. Moving on, you will learn how to think like a TDD developer when it comes to application development. Next, you'll focus on writing tests for new/changing requirements and covering newly discovered bugs, along with how to test JavaScript applications and perform integration testing. You’ll also learn how to identify code that is inherently un-testable, and identify some of the major problems with legacy applications that weren’t written with testability in mind. By the end of the book, you’ll have all the TDD skills you'll need and you’ll be able to re-enter the world as a TDD expert!
Table of Contents (21 chapters)
Title Page
Packt Upsell
Foreword
Contributors
Preface
4
What to Know Before Getting Started
Index

What is legacy code?


Most of you have probably had to work on a dreaded legacy project. Working on that project is no fun; the code is a mess, and you want to find whoever wrote it and find out what they were thinking when they wrote it.

At some point in your career, you have been or will be that person to someone else. We all write code that we will not be proud of later. But why does the code get so bad? When does a project become legacy? Lastly, what can be done to prevent this?

Why does code go bad?

In short, code goes bad because we are afraid to change it. Why would the code not changing cause it to be bad? You would hope that, when the code was written, it was the best code that developer was capable of producing at the time. So, that code should have been good, right? This is a complicated answer, but assume, for the moment, that the code was something to be proud of when it was originally written. That still begs the question, how did it go bad?

The answer is staring you in the face...