# Next Steps

You've completed this guide and gotten a taste of outside-in test-driven development on the frontend. I published this guide for free because I hope it helps people. If you've benefitted from it and/or have feedback, I would love to hear from you—please get in touch!

This guide was just the beginning of your journey. Here are some more suggestions to take your learning further.

Some of the links to book 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.

# A Community of Practice

Doing agile development with other people provides accountability to stick with it and insights when it's not clear what to do. Here are some suggestions for how to find others to do agile development with:

  • An easy first step is to chat on the Outside-In Frontend Dev Gitter (opens new window). You can join there to discuss what we've learned and how to apply it with the author (me, Josh!) and other readers.
  • If you're on twitter, you can tweet #outsideintdd (opens new window) to share your experiences and questions, or search for #outsideintdd (opens new window) to see who else is thinking about this approach.
  • Find a local meetup (opens new window) focused on agile development practices. "Software craftsmanship" is a common term for such meetups.
  • Attend a workshop on TDD or refactoring. Two instructors I would recommend are James Shore (opens new window) who focuses on JavaScript, and Sandi Metz (opens new window) who is so amazing that it is absolutely worth learning a little Ruby programming to take her course.
  • 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" is not enough: ask them what their agile process is like, and see if they have a thorough understanding of small stories, refactoring, and evolutionary design.
  • Share this guide with someone you think would benefit from it, and talk together about your experiences with it.
  • Sign up to receive email updates from OutsideIn.dev and other agile and TDD projects from the author, Josh Justice:

# Testing Tool Docs

Just like you learn your framework deeply, it's important to learn your testing tools deeply as well. This will show you what features you can draw from, give you ideas for how to test, and prevent buggy tests due to misunderstanding the test functionality. All of the tools we used have excellent guides, so I would recommend looking through them thoroughly:

# 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. It's written by the inventors of mock objects, and shows how mocking is intended to be used to isolate parts of your code, as we've done in our tutorial. This book has a more thorough description of the way outside-in TDD addresses change in software by producing code that has both high external and internal quality.

# Test Patterns

As we went through the tutorial, we made a lot of decisions about how to organize our tests. Most of these decisions were informed by xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. This is a programming-language-agnostic guide to how to create high-quality tests, and the principles apply directly to frontend JavaScript tests. In addition to providing ideas for how to arrange your tests, the book also provides a language for talking about test patterns and their tradeoffs. This can be helpful when guiding others, or when making a case to a team for changing unhelpful patterns.

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

# Refactoring

The functionality we wrote in this guide was pretty straightforward, so there wasn't much need for refactoring. But as real applications grow and change, the code gets complex, and it's essential to refactor it to avoid getting bogged down in cluttered code. Here are two options for learning about refactoring.

Refactoring: Improving the Design of Existing Code by Martin Fowler is the original book that presented refactoring as a disciplined process. It includes a comprehensive reference of different kinds of refactorings that will equip you with options to consider and clear steps to take. The second edition of the book was rewritten in JavaScript, so it's extremely accessible to frontend developers.

99 Bottles of OOP, by Sandi Metz and Katrina Owen, walks through one extended refactoring step-by-step, giving you the experience of what refactoring over time looks like. Don't let the "object-oriented programming" in the name fool you: even if you write your code in a functional-programming style, this book's principles of identifying code smells, listening to the code, and making small changes all apply just as well.

# Agile Methodology

This book has contained a brief introduction to agile development practices, but it hasn't gotten into 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. This is important because you can't deliver reliable software on a regular basis without technical processes to 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 draws out common principles.

# Epilogue

We've reached the end of this guide. I wrote it because I couldn't stop thinking about, talking about, and advocating for outside-in test-driven development and the other agile development practices we've looked at. And that's because they 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 that they are based on a realistic view of software development: a view that change is inevitable and people have limited capacities. They're the best way I've found to deliver value to my employers and to have a smooth and calm development experience.

And now you have a foundation and a taste of those practices. 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!