Author Archives: Jason Knowles

Code Review vs Unit Testing

With this semester coming to a close, I thought it would be appropriate to write about our most recent topic discussed (code review) and compare it with something widely covered during this course: unit testing. I found a great Codacy blog to aide my exploration of the similarities, differences and importance of these two topics.

Codacy explains that code review generally means to manually inspect the code, whereas unit testing is implemented to automatically detect bugs within the code. It seems to me that unit testing is focused solely on finding malfunctions (bugs) in a product, whereas code review considers the overall style, readability and functionality of that code as well.

Rather than asserting that one is superior to the other, Codacy suggests that both code reviews and unit testing ought to be done in all software projects. I feel software developers can produce efficient and supreme quality products when appropriately combining the two techniques. Thus I have to agree with Codacy regarding the implication that unit testing should not replace code reviewing, and vice versa.

The blog author gives a great example of why unit testing alone should not replace code review. It seems that there was an actual situation that occurred where a vast series of unit tests were run to ensure the integrity of a very important governmental system. But when the program was scheduled to go live, it failed to run. It turns out that the system was scheduled to launch on a Sunday, but the unit testing team only worked weekdays, thus unit tests were not run on the weekends. For one reason or another, it seems that code reviews had failed to be conducted for this governmental system.

My takeaway from the scenario described above is the fact that code reviews should have certainly have taken place. This is because I feel that code reviewers, through proper analysis, could have identified there was a flaw within the code that made the system inoperable during Sundays. Examples such as this solidify my belief that human analysis should be coupled with computerized testing. In a sense, code reviews “double check” the work of automated unit tests.

On the other hand, I also agree with Codacy in the sense that code review should not replace unit testing either. In regard to automated unit testing, computers generally have the capacity of identifying bugs at a speed that far exceeds the capability of the average person. Trying to manually replicate the work of automated tests in this sense just seems inefficient to me.

I found Codacy’s blog regarding “Code Review vs Unit Testing” to be engaging and informative. Based on what I’ve learned from the real world examples given by Codacy, I feel that code reviews and unit testing are equally important. My goal is to continue to learn and improve my expertise in code review and unit testing. I am confident that I will need both of these skills during my professional career.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Angular Project: “Clean-up” and Good Style Practices

My teammate and I are currently finishing up our Angular “Blackjack” project. The program seems to be running fine and doing everything we originally intended it to do. Now comes the important task of “cleaning up” our project. Examples of this are going through our program, rectifying any remaining bugs, and fixing any potential style inefficiencies within our code.

In order for us to clean up our code as efficiently as possible, I feel it is a good idea to brush up on ideal Angular style practices. By doing so, we can ensure our code is up to par with Angular standards. There is an excellent Angular Style Guide article that I strongly feel can help us in our “clean-up” task.

The guide is an article directly from the official Angular website. It gives examples of various “Angular style” coding techniques. Each is followed by a suggestion of whether the developer should (“do”) follow the example style, “consider” the style, or abandon the style (“don’t”) for a better alternative. I will outline certain styles mentioned in this article. I will also offer my personal takeaways on these style suggestions, as well as the Angular article in general.

General Naming Guidelines

Angular asserts the best practice is to name project files in a way that specifically identifies the function of that file. Each should follow the standard pattern of ‘feature.type.extension’. For example, our Blackjack project has a “player hand” component. Based on the suggestions of this article, we felt it was most appropriate to name each of the “player hands” companion files as ‘player-hand.component.ts’, ‘player-hand.component.html’, etc. Furthermore, the article suggests that each component, service, etc, along with their companion files, should all be located within the “src” folder in their own sub-directory. When going through the process of “cleaning up” our code, we will ensure that each section (service, component, etc) are in the folders they ought to be, in accordance with Angular standards.

Single Responsibility Principle (SRP)

The Angular article suggests that a project should follow the SRP whenever possible. Based on everything I’ve learned in the Computer Science program so far, it is always best to have a function to do just “one thing” as clearly and efficient as possible. Thus I feel it should follow that in Angular, we should only have the code for one component per file, one service per file, and so on. Though it is technically possible to write code for multiple types within one file, according to this article, it is bad practice to do so. When looking over our code, we will ensure we have all of our components, services, etc within their own appropriately named files.

The Angular article goes in great detail of good Angular style practices, and which ones to avoid. We have referenced this article a great deal during our project, thus I feel it directly relates to this course. I am sure this article will be useful during my professional career when working on additional Angular projects.

 

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Code Review: Strategies

We’ve recently conducted “group code reviews” on a given project, where the goal was to identify any issues and/or bugs we could find within the project’s code. I found this to be a good exercise because I will likely be doing many code reviews during my professional career.

My ultimate goal regarding code reviewing at this point is to learn how to do it as efficiently as possible. Sara Tansey has a great blog on the topic, entitled 7 ways to up-level your code review skills. She identifies several strategies in particular that she feels are important when reviewing code. I will outline a few of these strategies that I found especially relative to our course’s content, along with my personal thoughts and takeaways.

“Prioritize the goals of code reviews with your team.”

I feel this is an important topic which I am glad Sara mentions in her blog. The main idea here is to make sure your team is up to speed with what each individual team member should be looking for. One example I can think of is the following: perhaps “Person A” could be looking specifically for bugs while “Person B” concentrates on code style. Then perhaps each team member can go through the code together and see if there is anything they have missed.

“Run the app and try playing with the features.”

Sara brings up potential difficulties of trying to perform effective code reviews solely on the basis of reading the code. I agree with her stance that code reviewers ought to run the program and “play with” the features as well. I believe this is a good strategy because seeing the program in action may provide some clarification on what the code is doing, and what it is intended to do.

“Always give approval, unless you can prove that there is a bug.”

I believe what Sara is referring to here is a code reviewing team that has the responsibility of either approving or denying a developer’s request to continue with production. Giving approval to proceed barring the existence of bugs makes sense to me. There doesn’t seem to be much of a reason to halt production on the sole basis of “less than optimal code style” in my opinion. I feel if the code works, certain style inefficiencies can easily be addressed based on the feedback of code reviewers.

I enjoyed reading Sara’s blog and feel she brought up many good strategies to conduct efficient and high-quality code reviews. I especially like her suggestion that we ought to be running and going through the apps themselves, rather than just reading the code alone. Running the program might give us some context that we may have missed if we relied on simply reading code lines without actually seeing the app in action. During my professional career, I will adhere to Sara’s suggestions while conducting code reviews for given projects. I will run through the actual program as well.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Re: Angular, TypeScript and Final Project

My teammate and I are currently working on a Blackjack card game, which we will present to our class during finals week. I’ve spent the last few weeks trying to become more familiar with Angular and TypeScript for this project, and I believe I am starting to make some good progress. For instance, I have figured out how to build a card deck, shuffle it, and display images of these cards to the user.

There is a great online instructor named Mosh Hamedani with a series of tutorial videos for both Angular and TypeScript. I’ve already watched several of his videos and found them extremely useful and informative. The instructor has a personal blog as well. I would like to discuss one of his blog entries in particular, entitled Angular 4 in 20 minutes.

First, a disclaimer. I certainly did not learn Angular in 20 minutes, but Mosh’s insight and clear explanations are helping me understand Angular and TypeScript concepts more than any other tutorial I’ve tried so far. 

Mosh’s blog entry is a synopsis of one of his free tutorial videos, which is approximately two hours long. I’ve watched the entire video twice already and I believe it is definitely worthwhile to anyone who is trying to learn Angular and TypeScript. Here are a few important points that Mosh brings up in his video synopsis:

He explains that Angular is a framework for building applications in HTML, CSS and TypeScript/JavaScript. He also answers the question of why a developer would want to use Angular rather than other alternative methods. I have to agree with Mosh here that learning TypeScript with the Angular Framework seems a whole lot easier than, as he puts it, “vanilla JavaScript.” I believe this is due to the “IntelliSense” offered within Angular and TypeScript which is currently unavailable in JavaScript alone. When comparing TypeScript code side by side with JavaScript, in my opinion, the former is much easier to understand than the latter.

Mosh also goes through a step-by-step process on how to install everything needed to run the Angular framework, including how to create a new application project from the terminal. Next, he uses MS Visual Studio to go through the project layout and explains every single file that was created, including their functions and purposes. He then demonstrates how to generate new components within the project and how to connect them with the main application module.

The free video posted in Mosh’s synopsis blog entry is part of a 30+ hour long Udemy course video compilation that typically costs at least $200. Fortunately, there is a great “Black Friday” sale going on where I was able to purchase this entire course for just ten dollars. I feel I am making great progress in learning Angular and TypeScript; I honestly believe it would have not been possible without his videos and blogs. I am certain I will continue to reference Mosh’s insightful blog entries and tutorial videos, and apply what I’ve learned from him during my professional career.

 

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Why TypeScript?

We’re beginning to work on our final class projects using Angular and TypeScript, both of which I was previously unfamiliar with before this semester. Since our projects will be implemented using the Angular framework and the TypeScript programming language, I want to learn more about the concepts behind these applications. I found an informative blog on the subject; it is entitled Angular: Why TypeScript? by Victor Savkin. The main topic here describes the benefits of using TypeScript in general, and how it is an efficient means of producing quality Angular projects.

Victor points out that while using TypeScript for Angular projects is not required, but is encouraged to be used within the framework for several reasons; many of which I will summarize here. I will also offer my personal thoughts and takeaways regarding the content.

Prior to reading Victor’s blog, I was not familiar with the fact that Angular was written in TypeScript. Now it makes more sense to me why we are going to be using TypeScript to code our projects; since Angular was written in TypeScript, it ought to have high compatibility with that particular language.

Another encouraging aspect brought up by Victor is the fact that TypeScript is equipped with many useful tools, such as “auto-completion, navigation and refactoring.” Based on his explanations, I feel that TypeScript is a very flexible language; for example, if we need to rename an instance, it seems that TypeScript will automatically change all implementations of that instance to its new name without having to do it manually. I find this to be a very powerful and efficient feature that I look forward to using while coding future projects.

Victor also eludes to the fact that TypeScript is actually a superset of JavaScript, something I was completely unaware of. I find this fact very interesting in the sense that it suggests that anything that can be done in JavaScript can be implemented in TypeScript. Victor even suggests we can rename a JavaScript .js file with the .ts extension, and with the proper annotations, the program could theoretically run completely in TypeScript.

Victor further explains that TypeScript simply makes code “easier to understand” rather than other languages such as JavaScript. I tend to agree with him in the sense that it seems that TypeScript offers explicit declarations, such as that of parameters, interfaces and abstractions. It seems that JavaScript does not offer much of this functionality. Victor offers sample code, first implemented in JavaScript, and then again in TypeScript. In my opinion, the TypeScript code is much easier for me to comprehend due to the explicit declarations that are lacking in JavaScript.

Reading Victor’s blog has made me further intrigued with the capabilities of TypeScript; I learned that it is even more flexible and powerful than I originally thought. Based on Victor’s insights, I feel that learning TypeScript will be useful to me during my professional career, since he states that it is widely used in the field of Computer Science.

 

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Stubs, Mocks and Service Virtualization

We’ve been discussing the differences between stubs and mocks, along with the fact that many software testers may initially assume the two are the same concept. But as we have learned, mocks and stubs are not synonyms; they are two different techniques used within unit testing.

I wanted to learn more about some specific differences between stubs and mocks, such as potential advantages and disadvantages of using each of these techniques. Wojciech Bulaty has an informative article on the subject. Before getting into the pros and cons of each aforementioned technique, Bulaty explains the main concepts of stubs, mocks, and service virtualization.

He asserts that stubs use hardcoded data within the testing program itself, where the tests depend on this data. Based on Bulaty’s description of stubs, it seems it would be most beneficial to me to apply stubs when testing simpler code where no more than minimal implementation of an interface is required.

Mocks on the other hand seem to be most useful in situations for larger, more complex tests to “verify output against exceptions.” In my opinion, mocks ought to be used in addition to stubs to further satisfy the integrity of our testing. For instance, mocks may produce findings that stubs could not, due to the limitations of the hardcoded data within stubs. On the other hand, I feel it may be useful to use stubs as well, to help compare its findings with that of the mocks within our tests.

Bulaty introduces a third method to use within our unit tests: service virtualization. I found this particularly interesting because we haven’t discussed much about service virtualization in class yet, and this article helped me learn more about it. He explains that service virtualization supports testing through multiple protocols, and employs “test doubles” which are usually offered as Software as a Service (SaaS). It seems to me that service virtualization relies more on recorded data from a wide scope of different projects, whereas stubs and mocks are typically written by developers of their own projects.

My main takeaway from this article was recognizing some differences in particular between mocks, stubs, and service virtualization that were previously a bit unclear to me. Whereas stubs seem to concentrate on state verification, mocks tend to be more focused on behavior interactions within our code. I also learned which testing techniques may be most appropriate in regards to the particular code we are testing. For instance, if I am testing simpler tests with limited resources, based on what I’ve learned from this article, I will likely use stubs for my testing. But for larger, more complex tests, I feel I ought to implement mocks within my testing as well. Finally, when I am involved in large scale projects during my professional career, Bulaty’s article has convinced me that I should look into using service virtualization in addition to stubs and mocks when performing unit testing.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Give up Unit Testing? Uncle Bob Says No

Over the past few weeks reading about unit testing, I’ve come across a few articles and blogs claiming that unit testing is not the most efficient way to ensure code accuracy and quality. I’ve been under the impression that unit testing is always a good idea, so I wanted to read about Robert Martin aka Uncle Bob’s input regarding this subject. He is a reputable computer programmer and the author of the well-received book “Clean Coder.” The following is a brief summary, along with my personal takeaways, from one of Bob’s blogs entitled First-Class Tests.

Bob is critiquing a TechBeacon blog where the author is condemning unit testing as bad practice. It seems to me that the TechBeacon blog author has claimed to “give up” unit testing for something that he calls “system testing.” But Bob insists that the TechBeacon author is not only running his tests in an inefficient way, but using improper terminology as well.

Bob gives a few definitions of different types of testing, some of which seem to contradict the views of the TechBeacon blog author. First, he explains that unit tests are written to ensure that the code is doing what the programmer intends it to do. Bob then gives his definition of system testing, stating it is not what the TechBeacon author believes it to be. System testing, according to Bob, are “plumbing” tests to ensure the internal workings of the entire integrated system is working as expected. This is in contradiction to the TechBeacon blog who claims he is running “system tests.” Bob claims what is actually being run here is “user-interface to database” functional tests, which are, in actuality, slow unit tests. I agree with Bob’s terminology here; it seems to coincide with what we’ve learned in class regarding unit testing thus far, some of which I’ve discussed in some of my previous blogs.

I believe the main point that Bob is trying to get across is that it seems many people tend to have the wrong idea of what unit testing is. If someone is writing unit tests that rely too heavily on outside resources, for example, it can slow down and hinder the whole purpose of testing software. It can make unit testing seem inefficient, when in actuality is the result of badly written unit tests. He stresses that programmers should not be trying to think of ways to circumvent unit testing. Instead, we should find ways to write unit tests as efficient, clean, and self-sufficent as possible.

I truly enjoyed reading Bob’s blog regarding his opinion on unit testing. I found it both amusing and informative. Bob leaves us with a final thought; we ought to treat our unit tests as “first-class citizens.” I will strive to do this throughout my professional career based on the advice he has given in his blog: I will avoid coupling unit tests with outside resources and make great efforts to always keep my unit test code “clean” and up-to-date.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.