# 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.
Note that none of the links to products below are affiliate links; I don't make any money off of them. These are just resources that have helped me that I want to pass along. For published books, I link to Pragmatic Bookshelf and InformIT because they offer DRM-free ebooks. They are all available through other channels as well.
# 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. 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 to share your experiences and questions, or search for #outsideintdd to see who else is thinking about this approach.
- Find a local meetup focused on agile development practices. "Software craftsmanship" is a common term for such meetups.
- 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
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.
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 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.
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!