Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Practical Test-Driven Development using C# 7

You're reading from   Practical Test-Driven Development using C# 7 Unleash the power of TDD by implementing real world examples under .NET environment and JavaScript

Arrow left icon
Product type Paperback
Published in Feb 2018
Publisher
ISBN-13 9781788398787
Length 442 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Authors (2):
Arrow left icon
John Callaway John Callaway
Author Profile Icon John Callaway
John Callaway
Clayton Hunt Clayton Hunt
Author Profile Icon Clayton Hunt
Clayton Hunt
Arrow right icon
View More author details
Toc

Table of Contents (16) Chapters Close

Preface 1. Why TDD is Important FREE CHAPTER 2. Setting Up the .NET Test Environment 3. Setting Up a JavaScript Environment 4. What to Know Before Getting Started 5. Tabula Rasa – Approaching an Application with TDD in Mind 6. Approaching the Problem 7. Test-Driving C# Applications 8. Abstract Away Problems 9. Testing JavaScript Applications 10. Exploring Integrations 11. Changes in Requirements 12. The Legacy Problem 13. Unraveling a Mess 14. A Better Foot Forward 15. Other Books You May Enjoy

Dealing with legacy problems


We have been discussing all the issues with legacy code. Now it is time to tackle solving those issues. The first thing we must do is bring sanity to the targeted legacy code, and then we can begin testing and eventually fix the code and bring it back from death.

Safe refactoring

The term refactoring is often used incorrectly. When refactoring, you are merely changing the structure of the code. If the logic and/or signature of the code in question changes, then this does not qualify as refactoring. This is a change; most likely a breaking change.

If I'm changing the structure of the code (refactoring), then I don't ever change its behavior at the same time. If I'm changing the interface by which some logic is invoked, I never change the logic itself at the same time.

– Kent Beck

A safe refactoring is one that is guaranteed to not accidentally break the code. Other changes that aren't intended to actually change the behavior of the code but could do it accidentally...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image