Refactoring Components

As much as we all like working on greenfields projects, most of the work we actually do is on existing codebases. And existing codebases have technical debt. Technical debt makes code hard to modify. Being hard to modify slows down to development. So, how do we deal with this? We refactor! But, refactoring is an inherently risky process. It's very easy to break things in any complex system, especially if the test coverage is less than ideal. Worse, it's possible to ruin users' experience by accidentally fixing bugs that their workflows had come to rely on. To combat this we need to ensure that our refactor doesn't change the existing behaviour in any way, while also leaving us free to add new functionality. We're going to have a look at how to decide when we actually should refactor, and how we can use tests to ensure we maintain the existing behaviour. We'll have a look at our options for testing JSX, and the pros and cons of snapshot tests. And we'll finish up with a demo, putting it all together.