Writing Great Unit Tests

Unit testing was one of the types of testing that I had played a little bit before. Therefore, when I found this blog entry about Writing Great Unit Tests: Best and Worst Practices, I decided to choose it to understand more about unit testing and check if all the unit tests that I wrote in the past were good or bad. Below was the URL of the blog entry:

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

In this blog, Steve Sanderson discussed about unit test and the tips to write great unit tests. He mentioned that it was overwhelmingly easy to write bad unit tests that add very little value to a project while inflating the cost of code changes astronomically. In his opinion, unit testing was not an effective way to find bugs or detect regressions. Unit testing was more about designing software components. He also compared good unit tests with bad unit tests, and provided some tips to write great unit tests.

Steve explained the reason he thought that unit testing was not an effective way to detect bugs or regressions. I agreed with him that only proving component X and Y both worked independently did not prove that they were compatible with one another or configured correctly. Therefore, bugs still might occur when the application was run. This absolutely reduced the effectiveness of bugs detection. Before reading this blog entry, I never realized that unit testing was not that suitable to find bugs like that. Furthermore, Steve provided a table to identify which type of test we should use for different purposes like finding bugs, detecting regressions, or designing software components.

Steve also gave some tips about writing good unit tests. In my opinion, some of them were very basic, but Steve still included them. I thought that was because he saw a lot of bad unit tests had those mistakes. He recommended not to make unnecessary assertions because unit tests were a design specification of how a certain behavior should work. Including multiple assertions only increased the frequency of pointless failures. Moreover, the unit tests’ names should be clear and consistent. Personally, I liked the way he used to name the example unit test. It helped you quickly identify the subject, the scenario, and the result of the unit test. This way of naming was more descriptive than the way I always used. I would apply it the next time I wrote tests.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.

https://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

Seeing as we’ve started learning about design patters in class recently, I decided I’d explore a pattern further in depth.  Seeing as the singleton pattern was the last covered in class it was the one I chose.  Where most other sources would just condemn it as a bad practice, the article linked above does a good job of exemplifying both the pros and the cons of using the singleton design pattern.  One of the pros, something I learned as well, was how singleton classes can save memory by using lazy instantiation.  Opting not to assign memory to the variable until called; this method can create errors as well.  If multiple threads access the instance at the same time it will create multiple instances of the singleton class.  There are synchronizing techniques to get around the issue but it’d most likely be easier to use static initialization.  In static initialization, memory is allocated when the variable is declared.  The only difference this makes in the code is moving the creation of the object to where the variable is being declared.  Inheritance with singleton classes seems straightforward enough.   Any class inheriting from it will create more than one instance of the class thus violation the principle that only one instance can exist. However, if you wanted multiple singletons to inherit the same behavior, the code could be provided in an abstract class.  Although this may seem purely a shortcoming, it does prove itself when compared to static classes inability to work from interfaces.  One of the other major drawbacks that I learned about was that singleton classes couldn’t accept parameters which contributes to their limited flexibility.

The singleton pattern has me a bit conflicted with its use in java.  Although it seems like an easy way to create global variables in java, many of its drawbacks seem very limiting or painstaking with more complicated programs.  The linked article does, however, do a great job of showing and explaining how to create singleton classes and will differently be my go to for a reference.  Reading it was a great auxiliary to the lectures given in class.  Seeing how singletons work (and don’t), in depth, has also raised my confidence with working with them.  I’m sure that having a complete understanding of this design pattern will be useful as a tool to compare and understand the behaviors of other patterns.

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

Today’s blog post is about the Strategy design pattern. I found a blog on the Strategy pattern called “Design Patterns: Strategy”. This blog talks about the pattern, what it is, and how to implement it. The Strategy pattern is a way to get classes to interact nicely with each other, and keep code somewhat clean and manageable. The author of this blog uses the video game Overwatch as an example to showcase how the Strategy pattern works. In the Overwatch game there is a superclass Player, and Player has many attributes. In this demonstration, the author labels these primary_ability, secondary_ability, and ultimate_ability. These are all subclasses to the superclass Player. This seems like a pretty simple relationship that is easy to manage, which is true until you find out that there are 21 forms of playable characters. This, in essence, means that now all of those classes get multiplied 21 times. This makes code very labor intensive and difficult to organize. There should be a way to connect each of the 21 different character classes to only one primary_ability, secondary_ability, and ultimate_ability classes; rather than write those classes out 21 times. Additionally, each of the 21 classes would have to be overriden to cater to the different character classes. To remedy this, the author creates a series of classes (or “Strategies”) to keep from having to write out the classes 21 times, uniquely each time. Now, each version of the character class can inherit the Strategies, which hold the basic methods, and tailor them to the specific character by overriding them. Then, the character gets passed to the Player class. In the end, the Player class just gets passed a character, without having to know any specifics of attributes.

I chose this article because we just finished learning about the Strategy pattern in class, and we have an assignment coming up which uses this. I want to fully understand this before I take on the assignment, because I want to do the assignment correctly. The Strategy pattern is a rather straightforward software design, but it is extremely effective. I think that this reinforced my understanding of the Strategy design, and helps me to clearly see how the classes relate to each other. Before reading this article, I had a good understanding of the pattern, but the examples presented in this article helped me really get what the Strategy pattern is all about. I hope that now I will be able to implement the Strategy pattern without any issues, when dealing with a parent classes that have a multitude of similar subclasses.

Here’s the link to the blog:

https://www.madetech.com/blog/design-patterns-strategy

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Today, I am going to review and summarize Episode 283 of Software Engineering Radio.  This episode’s guest was Alexander Tarlinder, author of “Developer Testing: Building Quality into Software”.  The topics covered in this episode are quite relevant to the other posts I have done and one of those topics is specification based testing, which we have discussed in class.  I also selected this episode as the subject of this post because Alexander provides tips on how to test software effectively, both as a developer and as a tester.  The episode begins with Alexander providing an explanation as to why he wrote his book – he felt there were gaps within the software testing literature that needed to be bridged.  He claims that much of the existing literature on software testing will often focus too heavily on documentation, focus on a specific tool too much, or leave out crucial information on what to include in your test cases.  This can be hard to relate to for developers.  He defines general software testing as a process used to verify that software works, validate its functionality, detect problems within it, and prevent problems from afflicting it in the future.  He defines developer testing similarly but with the caveat that developer testing more systematically tackles the hard cases, rather than the rigorous; this is a result of developers being knowledgeable about the programming techniques implemented and the inherent bias that accompanies that.  Alexander argues that bias possessed by developers necessitates the need for additional testing to be performed by unbiased testers.  He insists that it is still necessary for developers to perform their own testing, though.  By performing testing during development, it ensures that at least a portion of testers’ workload will be a more of a “double-check”, allowing them to focus on the rigorous and unexpected cases that developers might overlook.

Alex then summarizes the main points of the discussion and provides tips on how to improve software testing.  The conversation strays a bit, so here is my summary and what I took from it:

• Encourage developer testing – Developer testing is a necessary practice to both ensure that the finished product is of high quality and functional and to allow testers to work rigorously, which will detect and prevent any potential problems in the future.
• Adopt an Agile development strategy – Agile development allows for rapid delivery of product and forces developers to adhere to effective working practices.
• Write code that is testable – Consider a Develop by Contract(DbC) approach where the caller and the function being called programatically enter into a “contract” with one another.
• Learn various techniques – Specification-based testing is a fundamental testing technique to learn, but it can sometimes lead to an approach that is too focused on where the data is partitioned, neglecting the in-between cases.

I think that this discussion contributed to my knowledge of effective development and testing practices which will help me a great deal when it comes time to implement them in the field (or an interview).

This blog post(2/9) is part of an assignment for the Fall 2017 session of CS443 @ Worcester State University.

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

We’ve been talking about path testing in class, such as tracing the concepts and expected behaviors of our code through a series of program graphs. I wanted to learn more about the different variations of path testing, and I found a good blog regarding this topic.

EngineYard: Ben Lewis – Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

According to Lewis, happy path testing is one that developers take when testing for expected behaviors. But Lewis states it is imperative we take unexpected actions into account as well. Rather than solely thinking like a developer, we should be also thinking like an end user; the “actors” who are going to be using our finished products.One way of evaluate a myriad of action-consequence scenarios an actor may encounter is to follow a series of testing paths:

The Sad Path
In Lewis’ blog, he describes the “sad path” as one we should follow when we are testing our code.  He suggests it gives us insight on what should happen when an “actor” does something we don’t intend the person to do. If a user submits invalid information for example, we should run tests to determine that we are providing an appropriate response to this. This may include highlighting why the information is invalid, and prompt the user to reenter something that is valid instead. I feel that the significance of “sad path” testing is to ensure that our projects are as user-friendly as possible.

The Evil Path
When we take the “evil path” approach, we ought to be putting ourselves in the mindset of a malicious actor. For instance, we should run tests attempting to infiltrate sensitive information that we expect to be secure.  I believe “evil path” testing is important because we should have our users privacy and security in mind when developing our projects.

The Weird Path
Lewis suggests that taking the “weird path” is when we look for problems that may occur beyond our control. For instance, perhaps a portion of our project needs a certain server to be active in order to function properly. In this case, we should test that our program is appropriately detecting that the server is online, and if not, perhaps we can redirect the actor to an user-friendly status page to inform the user when the server is likely to be available.

The Happy Path
Last but not least, we should test the “happy path,” which can be described as ensuring that our project is behaving as intended. If our code has a submit form for instance, we should ensure that our code is submitting the information appropriately.

My main takeaway from Lewis’ blog is that the end user (actor) does not always interact with our projects in a manner that we may expect. Rather than simply testing expected behaviors, I feel we should evaluate possible unexpected behaviors that an actor may choose to do as well. I intend on doing this during my professional career when testing future 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.

This week I read a blog post from TestLodge talking about the characteristics that make up a good software tester.  The post found at https://blog.testlodge.com/characteristics-good-software-tester/ helps identify some of the attributes that a tester should have in order to be proficient in their testing as well as excel in their career.  I chose this post because it provided a different perspective than most.  As a student initially learning these skills I often get too focused on how to do different testing procedures and sometimes forget to look at why I’m doing them and what purpose do they have. Articles and posts like this help me to take a timeout and look beyond the skill set that I’m trying to acquire to help put me in the right state of mind.  The post breaks it down into 13 different characteristics.  Characteristics like testers have to be a strong communicator and be a team player.  This is good to remember, especially early on in our careers, so that we don’t ignore failed tests or improperly communicate what failed in the software to the rest of the development team and let an inferior product be released simply because we were to scared of upsetting someone by telling them part of the code is wrong.  Other characteristics like thinking creatively and paying attention to details.  These attributes will help us examine closer what the goal of the test that we need to write is and think outside the box in order to write the most effective test.  We need to be able to realize that just because we did a test a certain way in class for a project one time, that may not be the best way to write the test every time.  A good tester should also be organized and should meet deadlines.  Time management is crucial in the software development process.  Staying organized with all your tools, notes, and team communications will allow you to complete more tests.  It will also help you keep track of your deadlines and prioritize your tests so that way you are not delivering a product late of missing important tests and creating too many tests for less important features.  I felt like this post is good to revisit from time to time so that I don’t get too focused on just trying to write a perfect test and develop a broader skill set that allows me to recognize the right approach to each situation and to stay organized without rushing into a project and failing from the start.

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