Random bugs with debug_trainer
Tags: codenewbie, javascript, showdev, elm
Published: 2020-08-04 01:01:46


[Original post: Kickstart Coding Online - Want to practice debugging without actually getting stuck? Introducing: debug_trainer!](https://kickstartcoding.online/learn/articles/introducing-debug-trainer/)

## The Problem

It’s possible to build some pretty nifty applications without having a good understanding of how the code is working. You copy and paste some online examples here, you try random things until one of them works there, and eventually you’ve got a sort of copy-pasted Rube Goldberg machine that basically works even if you’re not entirely sure how.

Eventually, though, something is going to go wrong that cannot be fixed without a decent understanding of what’s going on under the hood. And when that does happen it is scary and stressful and not at all the best time to discover that the plumbing of your code is a deep, impenetrable mystery.

Getting practice understanding your code and fixing problems with it before things like that happen can be incredibly helpful. Unfortunately, the only way to get practice fixing broken code is for your code to break, and broken code doesn’t happen when it’s convenient and you’d like some practice.

Although I think most coding schools have debugging exercises here and there, I have spent a lot of time wishing that we had some better ways to give students more regular practice with debugging.

Recently, I finally got a chance to take the time to sit down and write a tool for debugging practice that I’ve been thinking about making for a while to solve this exact problem.

## Introducing debug_trainer!

[`debug_trainer`](https://github.com/kickstartcoding/debug_trainer) is a terminal program that breaks your code! Run the `break` command on a file of your choice and it will introduce a random breaking change into that file (or several changes if you’re feeling adventurous). Then you, the programmer, can put your debugging skills to work and try to find the change that was made.

Let's say you've got a file, `my_file.py`, that looks like this:

```python
def greet(name):
    print("Hello, " + name + "!")

greet("Stacey")
```

You'd run `debug_trainer` like this:

```
> debug_trainer break test_file.py 


Breaking test_file.py...


...done!


Good luck debugging! I believe in you! Don't forget to make your program print things out if you don't know what they are. ❤️
```

And it might, for example, change the file to this (see the error?):

```python
def greet():
    print("Hello, " + name + "!")

greet("Stacey")
```

The changes it can make are all based on common issues I’ve seen students struggle with. It might change the first letter of a variable name from capital to lowercase. It might remove the word ”return” from a return statement in a function. It might rearrange or remove the arguments in a function declaration. Malevolent!

If you get stuck, you can ask `debug_trainer` to give you some hints with the `error-type-hint` and `line-hint` commands. `error-type-hint` will tell you what kind of change it made (for example, “somewhere in this file, `debug_trainer` changed the arguments to a function”). `line-hint` will tell you what line the change was made on. If you get really stuck, you can have it tell you exactly what it did with the `explain` command.

```
> debug_trainer error-type-hint test_file.py

HINT: somewhere in this file, debug_trainer changed the arguments to a function.
```

```
> debug_trainer line-hint test_file.py

HINT: The line where the change was made was line 1 of the original file.
```

```
> debug_trainer explain test_file.py

removed the name argument from greet on line 1 of the original file
```

And once you’re done, whatever file `debug_trainer` changed, you can reset it back to it’s working state with the `reset` command. Then you can do the same thing all over again as many times as you want!

```
> debug_trainer reset test_file.py

test_file.py has been reset!
```

I’m pretty excited about `debug_trainer` and I would love to get feedback, advice, suggestions for additional types of errors or new features, etc. I’d also like to give a special thank you to Dillon Kearns, without whose brilliant [tools](https://github.com/dillonkearns/elm-cli-options-parser) and [examples](https://github.com/dillonkearns/elm-cli-options-parser/tree/master/examples) I would not have been able to write this using my favorite language, Elm.

If you want to try it out yourself, just run 

```
npm install -g debug_trainer
```

to get started, then run the `debug_trainer` command to have it list all the commands and how to use them. Or check out the repo [here](https://github.com/kickstartcoding/debug_trainer) or the npm package page [here](https://www.npmjs.com/package/debug_trainer) for more details and usage examples.

And let me know on [the issues page](https://github.com/kickstartcoding/debug_trainer/issues) if you have any issues or feature requests!


[Original post: Kickstart Coding Online - Want to practice debugging without actually getting stuck? Introducing: debug_trainer!](https://kickstartcoding.online/learn/articles/introducing-debug-trainer/)