intro⌗

ft, the remote file browser, has its server written in the language Go. Go is a garbage-collected compiled programming language.

Normally, compiled programming languages cannot have incremental development. But, with Go’s specific features, one can achieve an experience close to incremental development.

but, why?⌗

Well, incremental development is extremely good. Think about this: You have a program that consists of 3000~ lines and one function is not working as it’s supposed to. Sure, in a language like Go, it’s very fast to compile a project and you could solve your bug that way, but I’d counter with three points:

  1. this isn’t guarnateed, what about when your project is heavy or is linked with C code
  2. what if you’re not using Go
  3. what if your code is a server and you need to process requests in-order to test a function.

Recently, this has happened to me with the function DirToCollection in the model package. Basically DirToCollection finds all the files in a directory and afterwards adds them to a Collection(an array of file information). Let’s take the following tree:

- S4
- S4/1.mp4
- S4/2/episode.mp4
- S4/3/episode/video.mp4

DirToCollection would then put all of those in an array that looks like this: ["S4/1.mp4", "S4/2/episode.mp4", "S4/3/episode/video.mp4"] but instead, it does this: ["1.mp4", "2/episode.mp4", "3/episode/video.mp4"].

At first, I went with the naive way of debugging, which consists of three steps:

  1. Modify the code
  2. Restart the server
  3. Verify the results with the client

Between these steps, I’d lose miniture time because whenever I see the browser, I’d go google something, look at something in YouTube, or some other distraction. Not only that but it often yielded very little to no results as the debugging messages weren’t that helpful. The cycle continued for a long while until I had a terrific idea: why not create another way to debug?

Well, curl requests could technically work, so I started out with those. But afterwards, I realized curl was also inefficient.

It turned out, after a ton of experimentation, unit tests were the closest thing to an interactive development experience in a compiled language. For three reasons:

  1. Most unit tests start out with a specific environment in-mind(no need to replicate environment)
  2. Tests are fast to run lest you make them slow
  3. Creating specific unit tests could prevent the issue from appearing again.
  4. Even if your tests are slow, you can run specific tests at a time.

a practical code sample⌗

So, for the DirToCollection function, I modified the NewOperation test and checked out the output of the Operation sources. If it matched the old ineffective one, it needed re-adjusting.

Surprisingly, I spent about an hour on this issue and when I switched to unit tests, I spent about 5 to 10 minutes and it was fixed. The solution also made sense unlike most of my bug solutions where I don’t know why the code works.

conclusion⌗

Use tests. Use them. No, seriously, use them. Unless you use an interpreted language like Javascript or Python, use tests to debug specific code. Because, it is faster, it is cheaper(no need to setup an environment), and the side effects are rather blatant.

For those are curious, the reason DirToCollection didn’t work was because FsToCollection found all files in a selected filesystem. That filesystem was provided by DirToCollection and is actually a BasePathFs provided by the afero package. So, essentially the directory would always be omitted out of the file paths.

A fix to this was to literally modify the paths before returning them, giving them a new filesystem and path that has this new behavior in-mind.