Test Driven Development

AUG 31

I finished the JavaScript course from The Odin Project!

This week, I went through some lessons covering computer science concepts (e.g. complexity, data structures, algorithms), intermediate Git, and test driven development with Jest as the testing framework.

Up to this point I’ve been writing a lot of code, but of course it’s also important to measure its efficiency. There’s two ways to measure code efficiency: time complexity and space complexity. Essentially, time complexity is the amount of time an algorithm takes to complete while space complexity is the amount of memory (perhaps space is easier to remember) an algorithm uses during its execution.

I won’t go into detail regarding the notations, but this Big-O cheat sheet is pretty useful.

I also won’t go into detail regarding data structures and algorithms, but it is quite useful to know what data structure to use in certain situations. The CS chapter of the course was quite hefty, though if you’d like to see how I built certain data structures with JavaScript, you can view some of the projects here.

Now, let’s talk about Git commands. The basics were already taught early on in the curriculum, but Git was revisited and some other commands are introduced.

Apart from the typical git commit, you can also do git commit --amend. This replaces our last commit with our new commit. It is important to remember though to only amend commits that have not been pushed anywhere.

The command git rebase integrates changes from one branch to another by moving commits to the latest point of the target branch. On the other hand, squash combines multiple commits into one. Then, we have git reset that moves your current branch to a different commit.

Though I have to admit, I haven’t used these commands in the projects that I’ve done. The trifecta of add, commit, and push has served me well for my projects so far. But if I ever do goof up something, I can always refer to those other commands I’ve mentioned.

This lesson explores how to use Git in the real world. It essentially goes over the workflow of how you would use Git to collaborate with people, say for example contributing to The Odin Project. Put simply, this is what you’d do: fork the repository, clone that forked repository, make some changes, push, and open a pull request. I glossed over some details, but that’s mainly how it goes.

In fact, so far in my journey, I’ve actually contributed to MDN and The Odin Project! Although these are minor fixes, it’s nice to know that I was able to contribute to resources that I actually use and benefit from, even if the contributions were quite menial.

Test driven development (TDD) was given great importance in its chapter. The idea behind it is that you first write the tests, and then you write the code that is being tested. This article by James Sinclair is a wonderful article that explains the value of doing TDD. A quote from the article:

Test Driven Development is not about testing. It is a way of thinking and coding that just-so-happens to involve tests.

The article also mentions two simple rules in TDD that imply three simple steps, taken from a book by Kent Beck named Test-Driven Development by Example:

  1. Write new code only if you first have a failing automated test.
  2. Eliminate duplication.

The three steps:

  1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first
  2. Green—make the test work quickly, committing whatever sins necessary in the process
  3. Refactor—eliminate all the duplication created in just getting the test to work

Doing TDD while doing my battleship project was very useful. Following this kind of principle really reinforces you to start small, and it eventually helps you out in the long run. I’m excited to practice TDD more in future projects!

That’s it for this week. I already started the Advanced HTML and CSS course, so I’ll be going over that next week (and maybe a little bit of React?).