 Finally, we're back in the green, all of your tests have passed and you're ready to submit your pull request. We're not going to do that for this tutorial, but when you're developing or you're working on something, that's what you would do next. Thank you for completing this tutorial. We hope that you feel more confident debugging Galaxy and understanding how to navigate the various testing frameworks that we use. Of course, we're always available to help answer questions and support you on Gitter, on Slack, wherever you can find us. And feel free to always come back to this tutorial whenever you run into a rough patch or you're not sure how to test something. And here are a few key points we hope you'll take with you. So always run individual failing tests locally to minimize the feedback loop. To fix a bug, start by looking for the precise location in the code where the unexpected result is being produced. Starting from that failing test or error message in the log, once the location is identified, finding and correcting the error is often trivial. It's little. When debugging an API test failure, first determine what endpoint is being utilized. Then look in LibGalaxyWebAppsGalaxyAPI to locate the controller that handles the endpoint. The controller will point you to a manager module located in LibGalaxyManagers, which is where you are most likely to find the bug. To locate the probable cause of the selenium test, try and run it with the headless browser. That's going to show you the browser running through the test, and it can really pinpoint where it's getting stuck. When debugging a runtime error, use the Python debugger, PDB, or any other interactive Python debugger to step through the code to identify the location of the error. Go to use galaxy underscore config underscore debug equals one environment variable to enable debugging. If you find a bug in a code block that is not covered by a test, before you fix the bug, write a test to expose that bug, run the test to ensure that it fails, then fix the bug, and run the test again to ensure it passes. That's called test-driven development, and it's a really good practice. And please, pretty please, with sugar on top. Write useful and properly formatted commit messages. That'll save you a lot of time. Just one more. That PDB Python debugger is your friend. Again, thank you for doing this with us. One other suggestion or request that we have for you is that you fill out the feedback form at the bottom of the tutorial. That way we know how we can make this better. Happy training. Good luck. Good luck.