As I progress more in my CS studies, I’m starting to move beyond learning how to write the code for a project to how the project should be designed overall. In fact, this is one of the main purposes of two of my current CS classes. This has lead me to learning about TDD, or Test Driven Development. I’ve come across a fantastic article by Andrea Koutifaris which outlines the concept well called Test Driven Development: what it is, and what it is not.

In this article, I’ve learned the purpose of writing test driven code and what the plan for doing it should be. In TDD, tests come first in the process while writing production code comes second. This is in order to almost put oneself in a user’s shoes. If I myself in the user, what do I want my code to do? This is where the tests come in. Once the goals are clear and defined, the production code can be written.

The rules for TDD can be broken down to two essential parts:

• “Write only enough of a unit test to fail”
• “Write only enough production code to make the failing unit test pass”

Tests must be written to be very specific and achieve the ultimate application goals. Analysis of your tests can help you determine a method to writing your production code. They often not only outline what need to be achieved, but how it needs to be achieved.

The next part of TDD would be writing production code. As outlined before, the second essential rule of TDD is to “Write only enough production code to make the failing test unit pass.” Had production code been written first, output may not match user goals and unnecessary code may be written, which comes with its own set of problems. The focus is on writing clean code and limiting the amount which you write.

The last part of TDD would be the “refractor phase.” This is where code can be changed to be better, but what is stressed here is removing all duplicate code and consolidating.

The result of TDD should be efficient, clean code which serves its purpose. Although it can seem long-winded and like extra work, it’s mostly just inverting the process which we usually work by, so once the process is learned and practiced, it can help with writing better code more coherently and more focused on user goals, which is the ultimate goal as a programmer.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

In my last week of working on my CS-343 final project, I was focused on implementing the remaining features that I had planned to add in my original wireframe. This included creating a working puzzle game that the player could customize and developing my layout further to make it more appealing. While I was able to create a puzzle game and clean up my layout a little, I was unable to get everything to work the way I intended before I presented the project on Friday. My final version of my project, and the one that I presented, looks like this:

As you can see, I was able to create a simple grid-based puzzle game, which was my plan from the beginning. While working on my layout and data service over the past week, I finally came up with an idea for a basic game I would be able to implement in time for the presentation. I decided to use a puzzle I have seen before, in which the player interacts with tiles on a grid to change their color as well as the color of all adjacent tiles. The goal of the puzzle is to make all tiles the same color within the time limit. I was able to create a new Angular component to represent my tiles that alternate between gray and white when clicked. However, my attempts to make them change the colors of adjacent tiles let to many issues. I had the puzzle working in this way temporarily, but it would stop behaving correctly after the player reset the puzzle for the first time. I think this had something to do with how I was recreating my array of tiles in TypeScript and how that interacted with the HTML files. Clearly, I am still not an expert in TypeScript or HTML, even after a month of working on this project. Since I couldn’t get the puzzle to work the way I wanted, I ended up settling for a game where only the tile that was clicked would change colors. This makes the puzzle extremely easy, but at least it works consistently.

Aside from my troubles with the game mechanics, the rest of the development went pretty well. I was able to change the behavior of my width and height forms to alter the dimensions of the puzzle in tiles instead of the dimensions of a rectangle in pixels. I was also able to implement a timer that could have its time limit customized as well. If this timer runs out, a message displays saying that the game is lost. If all tiles are made white within the time limit, a victory message displays and the timer stops. You can see the application in action in the following screenshots:

Overall, I found this project to be an enjoyable experience that taught me a lot about creating web applications using the Angular framework. It not only taught me how to work with TypeScript, HTML, and CSS, but it also helped me figure out how to create GUI layouts in HTML using <mat-grid-list> and how to pass data between components using a data service. While my difficulties getting the game to work correctly prevented me from implementing everything I wanted to, such as a more appealing GUI or a back-end server to save player scores, I think the experience will definitely help me write better single-page applications in the future.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.