Making Sense of Static Testing

Last week in CS-443, we did a class activity on static testing tools. These tools are able to detect issues in a program without executing the code. Previous activities had focused on dynamic testing, which does involve code execution, so static testing was definitely new to me. However, I had a hard time learning about the tools due to problems I had with the activity. One of its early parts involved building and running a batch file for the project we were working with. This batch file refused to run properly on my computer, so I was unable to progress with the activity and thus did not get to work with the static testing tools for myself. I observed what my group’s technician did with the tools, and it was interesting to see them in action, but I had a hard time understanding what the tools were doing since I was not working with them myself. Today, I decided to address this problem by revisiting the activity on my own and doing extra research into static testing.

Unfortunately, I was unable to get the batch file to run on my computer. No matter what I tried, it always failed to find or load the main class of the project. After about an hour of messing with file directories, I decided it was not worth spending more time trying to get the batch file to work. I was able to run the project using the gradle run command, and I decided to move on so I could actually try working with a static testing tool. The tool I worked with was Checkstyle, which looks over the code and makes sure it complies with the style guidelines specified in an xml file. I found it interesting that the tool is fully customizable, as the guidelines it checks for can be changed by altering the xml file that the tool uses. The tool is also extremely simple to add to a project, as it only requires a few extra lines in the build.gradle file: one to add the plugin, one to state which version to use, and one to declare which xml file contains the style guidelines.

Although I was able to figure out Checkstyle, I still was not sure I understood the fundamentals of static testing. I decided to do more research instead of continuing with the activity, and I came across an article from about the basics of static testing and testing review. I think the article does a great job introducing the concept of static testing and explaining why and how it is used. It is from reading this article that I learned the difference between static and dynamic testing. It also explained to me why static testing is used and introduced me to different types of static testing, such as manual reviews. I won’t go into every detail about the article here, but it definitely helped me make more sense of static testing and I certainly recommend it to anyone who is also confused by it.

You can find the article here:

CS-343 Final Project – Part 1

As there are now just a few weeks left in the semester, it is time to start working on my final project for CS-343. This project is to develop a Single Page Application in TypeScript using the Angular framework, which we have been learning in class over the past month. From now until the end of the semester, I will be making weekly posts documenting my progress with this project and what I learn while working on it.

My final project began with a proposal, for which I was to create a conceptual design for a Single Page Application using a wireframe. This helped teach me how to design a layout for an application’s components before programming it. My idea was to design a layout for a customizable puzzle game. When it comes to software development, my main interest is in making games. For this reason, I thought that using this project to make a basic game while also learning about creating Single Page Applications in TypeScript would be something I’d enjoy.

My current concept involves some kind of grid-based puzzle game, such as minesweeper. The user would be able to interact with a variety of components in an options menu to change the size of the grid as well as other aspects of the game, like the difficulty and time limit. Changes made to these options would update the main play area in real time without the need to reload the page. I also included a help menu that would contain instructions and potentially a hint button for extra interactivity in my proposal.

I drew my wireframe layout for this application concept on paper. You can take a look at it right here:

I still am not certain that this is the idea I want to go with for my project. I think it is a rather simple idea due to its lack of communication with a back-end server. I also have yet to decide on the details about the puzzle game itself, and I don’t know if such a game is even possible to make with angular components. I will have to do more research about Angular and TypeScript to help solidify my plan. Despite my doubts, I am looking forward to learning more about writing applications in TypeScript, and I will definitely get development started during Thanksgiving break.

Mock Testing

Recently in CS-443 I was introduced to testing using mocking. Mock testing makes use of a mocking framework (we used Mockito in class) to create mocks which the place of regular objects. A mock can call the methods of its associated class or interface, but it will return a default value of 0 instead of actually running the behaviors specified in the class’ methods. It is also possible to tell the mock to return specific values other than the default to make sure that different methods return different results. It was interesting to learn about implementing Mockito and working with mocks in my projects, but there was one question that I kept asking myself: What is the point? Why go through the trouble of setting up mocks when you could just finish writing the code and test its actual behavior? I decided I would search for an answer to these questions on my own, and in doing so I came across an article by Michael Minella titled “The Concept of Mocking.”

The article can be found here:

Unlike the example in class, this article teaches mocking and its purpose clearly and simply. This purpose, as the article explains, is to test functions without executing other functions that they depend on. The article demonstrates this with a simple example which includes a doLookup method that calls a lookupByKey method. By using mocks, it is possible to test doLookup without needing to make sure lookupByKey is also working correctly. This extremely simple example has helped make the point of mocking much clearer to me. It still seems better to me to write tests based on the actual code of a project, but I can see mocking being useful in situations where the code a project depends on is not all accessible. I think the example in class may have been too complex an introduction to mocking, and the difficulties I had getting the example code to work made it difficult for me to understand the basic concepts behind mocking. The simplicity of this article enabled me to see the purpose of mocking, which I think will make it easier for me to apply what I learned from the class activity.

Angular Components

This past week, I began to work with REST API frontend code using the Angular framework in CS-343. The introductory class activity taught the basics about setting up and working with an Angular project as well as some useful properties of Angular (such as *ngIf) that I definitely see myself using in the future. However, the activity did not go into much detail about how to create and manipulate Angular components to create more interesting UIs. While researching Angular on my own, I came across a blog post from Angular University titled “Angular Components – The Fundamentals.”

The blog can be found here:

As someone who has enjoyed creating UIs in Java using Swing components, this blog immediately caught my attention. I expected it to help me create UIs for server-based applications that would be more interesting than the basic layout I worked with in class. However, while this blog did not go into too much detail on the creation of UIs, it has certainly helped me to better understand the fundamental properties of Angular components. The information I learned from this blog will undoubtedly be useful as I begin to work more in-depth with Angular components in my final project for CS-343. I decided to share this blog because I think that others who are new to Angular will also find it to be a useful introduction to Angular components.

The blog starts by providing a basic introduction to Angular components, as well as browser components in general, using short example code. It then discusses in detail the two main aspects of an angular component, properties and events, and explains when to use them and when to avoid using them. I think the blog did a great job explaining properties and events in simple terms and clearly stating when not to use them. I especially liked how the blog links properties and events to input and output, respectively. This association helped me understand when to make use of properties and events in Angular projects, since I already have experience working with input and output of components in Java. I also think the example code in this blog is simple enough that it can easily be referenced while working on other projects. I certainly see myself referring back to these examples as I start working with Angular components on my own to help myself understand the correct syntax for implementing properties and events. Finally, this blog has demonstrated to me how to create familiar components, such as a scrollable list, and it has taught me how to change aspects of components, such as their color. The information in this blog has helped me understand the fundamentals of Angular components and how to work with them in applications. I will certainly be referring back to this post as I begin to work on my final project this week, as it is a great resource to help new Angular developers to understand Angular components.

The Single Responsibility Principle

Several weeks ago, we briefly discussed the SOLID design principles in CS-343. This discussion was supposed to lead into a homework assignment where we would research a couple of principles, but since this never happened I decided to research a SOLID principle for a blog post instead. In this post, I will be focusing on the Single Responsibility Principle, or SRP (the ‘S’ in SOLID). This principle declares that a class should have only one reason to change, or in other words, a single responsibility. It sounds like a simple concept, but actually implementing it can be challenging. My research into the SRP helped me come across a blog post by Patrick Smacchia titled “SOLID Design: The Single Responsibility Principle (SRP),” which defines guidelines that may help make the principle easier to follow.

The blog can be found here:

In the blog, Smacchia explains that the SRP is not as simple to follow as it sounds, because different programmers may define a responsibility or a reason to change in different ways. For this reason, he approaches the principle based on its fundamental purpose of determining which logic should be in which class. From this approach, he explains several aspects of the SRP using example code, and he provides a set of concrete guidelines that can help enforce the principle. I chose to share this post because Smacchia’s approach to explaining the SRP has helped me understand it better by getting me to think about it from a more fundamental perspective. I also think his guidelines would be useful to any programmers, myself included, who intend on following this principle in their projects.

I certainly intend on referring back to the guidelines included in this blog to ensure that my future projects follow the SRP. Although there are a couple I don’t fully understand, such as the one on POCO classes, I think the others will greatly help me adhere to the SRP. His suggestion to keep logic related to different functions separated into different classes makes sense thanks to his Employee example, which I will refer back to when deciding which functions should be separated into different classes. I found Smaccia’s discussion on cohesion especially interesting because it exposed me to the Lack of Cohesion Of Methods metric, or LCOM, which is used to actually quantify how cohesive a class is. It surprised me that a more complex class can have a lower LCOM score than a simpler one, and that a class’ simplicity does not represent its adherence to the SRP. I will definitely refer back to this blog to help me ensure that my own classes keep a low LCOM score even as they grown more complex as a way to follow the SRP. I have certainly had issues with classes getting too large and doing too many things in the past, and I think learning more about the SRP from this blog will help me avoid this problem in the future.

Adventures in TypeScript

This week in CS-343, I was introduced to TypeScript, a scripting language that uses typed variables to prevent coding errors caused by mismatching data types. My introduction to TypeScript was my first time working with a scripting language, and I am really looking forward to learning more about it and using it to write new kinds of programs. However, the tutorial I did in class was rather simple, as it only showed how to set up a basic project in TypeScript. To learn more about this new language, I decided to research TypeScript’s other features. I eventually came across a useful blog post by Nwose Lotanna titled “New Features in TypeScript You Didn’t Know Exist.”

Link to the blog:

As the title suggests, this blog post discusses several features of TypeScript that were introduced between versions 3.0 and 3.4. Each feature has a short description that explains why it is useful, and many are also demonstrated using example code. The post seems to be targeted at developers who are experienced with TypeScript, which made it difficult for me to understand every feature it discusses. However, there are a few features listed in the blog that I could definitely see myself and other newcomers to TypeScript making use of even in simple programs. I chose to discuss this blog to help spread information on these useful but often overlooked features.

The first feature discussed in this blog is project references. As of TypeScript 3.0, it is possible for one TypeScript project to reference another by referencing its tsconfig.json files. This feature is heavily reminiscent of the import feature in Java or the #include feature in C, which have proved invaluable in my experience. Having the ability to reference code in other files helps keep projects simple and organized, which will undoubtedly be just as important in TypeScript as it is in other languages.

Another feature discussed in the blog that caught my attention is TypeScript’s BigInt object. BigInt was introduced in TypeScript 3.2 and allows programs to use numbers greater than 253. While I can’t recall a time where numbers that large were necessary, it is nice to know that the option exists in TypeScript. There are certainly potential uses for such large numbers, such as the Fibonacci function that Lotanna uses to demonstrate the feature. Should I ever need to write a program that uses numbers of this magnitude, I would certainly take advantage of TypeScript’s BigInt feature.

A third TypeScript feature that I expect to be useful is the const assertion. Since TypeScript 3.4, it has been possible to declare arrays and objects as read-only constants using the syntax demonstrated by the example code in the blog post. Though the syntax is different, this feature seems to function just like C’s const and Java’s final keywords. Having used these features frequently, I expect TypeScript’s const feature to be useful in many programs to ensure that the values of certain variables cannot be changed.


The latest in-class activity from CS-343 introduced me to Representational State Transfer (REST), which is an architecture used by Client-Server APIs. The activity was helpful in explaining standard HTTP methods which are used by REST, specifically GET, PUT, POST, and DELETE, but it didn’t really focus on explaining what REST actually is and how APIs that use it are structured. For this reason, I decided to further look into the fundamentals of REST and how to use it. While researching, I came across a blog post by Bivás Biswas titled “How not to blow your REST interview.” The post can be found here:

While this blog does indeed give interview tips, it also helps explain REST and the design principles it follows. Biswas focuses on five main principles of REST that RESTful APIs follow, which include the contract first approach, statelessness, the client-server model, caching, and layered architecture. I chose to share this blog post because its organization of its information on REST helped make it easy to follow and understand. For this reason, I think the blog is an excellent resource for learning about REST, and I could see myself coming back to it as a reference if I work with REST in the future.

I liked that Biswas opened the blog by acknowledging common misconceptions about RESTful APIs that he has heard in interviews. One of these misconceptions was that RESTful APIs simply follow the HTTP protocol, which is a misconception I may have developed myself due to the aforementioned class activity being focused on HTTP. The fact that this was immediately stated as incorrect helped indicate to me that REST was more detailed and complex than I understood from class.

I also thought that Biswas’ approach to explaining the five principles of REST was particularly effective. He makes use of analogies and examples to demonstrate each concept instead of relying on technical terms that newcomers to the topic, such as myself, would likely not understand. For example, he explains the contract first approach with a mailbox analogy by suggesting that applications can get the same data without changing URIs in the same way that people can get their mail without changing mailboxes. Similarly, layered architecture is explained by comparing an API’s Gateway layer to a bed’s mattress. Much like a bed frame can be changed without affecting how the mattress feels, changing the fundamental layers of a RESTful API does not change how applications interact with the API’s Gateway. Analogies and examples always help make complex concepts easier to understand for me, and their use in this blog greatly helped increase my understanding of REST and its 5 core principles. I am by no means an expert on REST just because of this blog, but it has certainly helped prepare me to learn more about it in the upcoming class activities.

The Singleton Design Pattern

Recently in CS-343, I have been introduced to the concept of design patterns. These are essentially code-writing techniques that help make code easier to describe, modify and maintain. There are a wide variety of design patterns, each with different benefits and drawbacks. My last class on Thursday ended as we began to cover the Singleton Pattern, and so I decided I would look into Singleton in advance of our activities next class about it. My research led me to Andrew Powell-Morse’s blog post “Creational Design Patterns: Singleton,” which can be found here:

This post, as you may expect, is focused on explaining the Singleton pattern to the reader. Powell-Morse accomplishes this by using real-world analogies to describe the concept of Singleton and a programming example to show how the pattern can be implemented in code. I chose to write about this blog not only because it explains Singleton well, but also because I found the programming example interesting. The purpose of the Singleton pattern is to ensure only a single instance of certain classes can exist at a time, which Powell-Morse clearly states right at the start of the blog. This is a simple enough concept to grasp, but Powell-Morse elaborates further by explaining that Singleton should be thought of in terms of uniqueness rather than singularity. He uses real-world examples of uniqueness, those being individuality in people and a unique deck of cards used for poker games, to describe situations in which Singleton can be useful. These examples, especially the deck of cards, have helped me understand that Singleton is useful in programs that only require a single instance of a class, and I could definitely see myself applying this concept in future projects to help reduce memory usage from unnecessary objects.

Since I found the deck of cards analogy especially helpful, I was pleased to discover that it was the focus of Powell-Morse’s programming example. However, the example’s complexity made it somewhat difficult to understand at first. Instead of simply demonstrating how Singleton is coded, Powell-Morse applies the concept to a program using multiple threads that separately remove card from the same deck instance. I have not written many programs myself that use multi-threading, and this lack of experience made the example confusing initially. The example is also written in C#, which is a language I am not nearly as experienced in as I am with Java. Despite my initial confusion, I eventually understood the example and grew to appreciate its complexity. The use of multi-threading in the example helped demonstrate a major drawback of Singleton and how to work around it in C#. The example not only taught me how to implement Singleton into my future coding projects using static variables, but it also showed me how to work around Singleton’s issues with multi-threading. This blog post also taught me more about a language that isn’t Java, which is always welcome.

About This Blog

Hello, and welcome to my new blog!

As you might expect from the title, I will be using this blog to make posts about Computer Science. I have specifically created it for use with the following courses at Worcester State University:

  • CS-343: Software Construction, Design, and Architecture
  • CS-443: Software Quality Assurance and Testing

As such, for the time being, I will mainly be posting about software development! My interest in software development was the main reason I became a Computer Science major, and I am looking forward to discussing a topic I enjoy while attempting to blog for the first time. It should all be very exciting, so be sure to look forward to my future posts!

Create your website at
Get started