Skip to main content

Next Steps

You've finished this book and gotten a taste of outside-in test-driven development on the frontend. I wrote this book because I hope the principles that have helped me will help other developers. If you've benefited from it and/or have feedback, I would love to hear from you—please get in touch!

If you choose to continue on in outside-in TDD, then this book will be only the beginning of your journey. Here are some suggestions for ways to take your learning further.

A Community of Practice​

Agile development really sank in for me once I started doing it alongside other people. Fellow agile developers provides accountability to stick with your principles and insights when it's not clear what to do.

Here are some suggestions for how to find others to do agile development with:

  • Find a local meetup focused on agile development practices. "Software crafters" or "software craftsmanship" are common terms for such meetups.
  • Attend a workshop on TDD or refactoring. One instructor I would recommend is Sandi Metz, who is so amazing that it is absolutely worth learning a little Ruby programming to take her course.
  • Share this book with someone you think would benefit from it, and talk together about your experiences with it.
  • Start a book club with your coworkers to read through this book and work through the exercise together.
  • The next time you are looking for a new job, look for one that prioritizes agile development practices. Just hearing them say "we do agile" or "we do testing" isn't enough: ask them what their agile process is like, and see if they have a thorough understanding of small stories, TDD, refactoring, and evolutionary design.
  • Share this book with someone you think would benefit from it, and talk together about your experiences with it.

Testing Tool Documentation​

In the same way that an experienced developer will learn their programming languages and frameworks deeply, it's important to learn testing tools deeply as well. This will show you what features you can utilize in your tests, give you ideas for how to test, and prevent buggy tests due to misunderstanding the functionality of the testing tool. All of the tools we used have excellent guides and I would recommend reviewing through them thoroughly:

Books​

If you get the opportunity to work on a team with someone who has helped push agile practice forward, take it. Unfortunately, we won't all get the opportunity to do so, but many of them have recorded insights in books to share them with a broader audience. Here are some recommendations.

Some of the links below are affiliate links: if you purchase through them I make a little money without any cost to you. If you’d rather not use these links, feel free to search for these books at your preferred bookseller. I recommend InformIT and Pragmatic Programmers for DRM-free ebooks.

Outside-In TDD​

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce is the book that introduced outside-in test-driven development. The authors are also the inventors of mock objects, and over the course of the book they illustrate how mocking is intended to be used to isolate parts of your code, as we've done in our exercise. This book will help you develop an even deeper understanding of the way outside-in TDD addresses change in software by guiding you to code that has a high degree of both external and internal quality.

Test Patterns​

As we went through the exercise there were many moments where we had to make a decision about how to organize our tests. Most of these decisions were informed by xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. This book is a guide to creating high-quality tests in any programming language, and its principles apply as well to frontend JavaScript as anywhere else. This book also provides a language for talking about test patterns you may have seen, which can help make conversations about organizing tests more productive.

To get a preview of a few of the book's test patterns and how they apply to JavaScript, check out a talk I gave based on it at Assert(js) 2019, "Old Solutions to New Testing Problems".

Refactoring​

Over the course of this book we did a little refactoring, but not much: by and large the functionality we wrote was pretty straightforward. Real applications are different: as they grow and change, the code gets complex and it's essential to refactor to avoid getting bogged down. Here are two resources for learning about refactoring.

Refactoring: Improving the Design of Existing Code by Martin Fowler is the original book that introduced refactoring as a disciplined process. It includes a comprehensive reference for different kinds of refactorings, helping you understand when you would want to apply them and how to do so. The second edition of the book has all of its examples written in JavaScript, so it's very easy for frontend developers to pick up.

99 Bottles of OOP is by Sandi Metz, Katrina Owen, and TJ Stankus. It walks through one extended refactoring process step-by-step, giving you the experience of what refactoring over time looks like. It's available in JavaScript and several other programming languages. Don't let the "object-oriented" in the name fool you: even if you write your code in a functional-programming style, you'll be able to apply this book's principles of identifying code smells, listening to the code, and making small changes.

Agile Methodology​

This book has briefly introduced agile development practices, but there is much more to consider about the broader scope of doing agile as a team. There are many books on agile development; here are two I would recommend.

Extreme Programming Explained: Embrace Change is by Kent Beck, the creator of Extreme Programming, one of the early agile methodologies. Beck is also the creator of test-driven development. Unlike some other agile methodologies, Extreme Programming is not agnostic about technical practices, but rather makes very specific recommendations. This is important because you can't deliver reliable software on a regular basis without applying technical practices that keep the software reliable and development speed consistent. Extreme Programming Explained also gets into the big-picture values behind Extreme Programming, such as the fact that humans have limited capacities and we should design software practices that acknowledge and support that, rather than deny it.

The Nature of Software Development, by Ron Jeffries, is a recent attempt to restate the values and priorities of agile development in a methodology-agnostic way. Rather than teaching a complex approach, it lays out principles common to agile methods and makes a case for them.

Epilogue​

I decided to write this book because I found that I couldn't stop thinking about, talking about, and advocating for outside-in TDD and other agile development practices. And the reason I couldn't stop is that I've seen them solve a problem that I haven't seen solved any other way: the problem of development slowdown over time due to code that is hard to work with.

New languages and frameworks don't fix this problem, because you can make a mess in any language. More process doesn't fix the problem if the process doesn't account for change. Trying harder doesn't fix the problem, because we're human and have limited capacity.

The reason agile development practices work is because they're based on a realistic view of the world in which software development occurs. Alternate approaches to development envision a world where requirements can be fully understood and perfectly executed. That world is appealing to programmers and businesspeople alike, but its call is a siren song, and if you follow it you'll suffer for it. Instead, agile development recognizes that in the world we live in change is inevitable and people have limited capacities. It provides practices that work with the forces of this world, not merely to weather them, but to thrive because of them.

These practices are the best way I've found to deliver value to my employers and to have a smooth and calm development experience. It's no exaggeration to say that they've had a life-changing effect on me. And now you have a foundation in these practices and a taste of the results as well. I hope you'll try putting them to use in your development work. I think you'll like the results.

Thanks for reading, and keep in touch!