Author Archives: Kat Law

Some Notes on JUnit 5 Annotations

I think it is extremely cool that with a simple tag at the beginning of an individual Junit test, the entire execution of the entire collection of unit tests in a given source file. When reading about tags such as @BeforeEach and @BeforeAll after going over it briefly in class, I came across an article which describes the most common tags used for Junit tests, found here:

Some of these tags are repeats from what we have discussed in lectures, but I find it helpful to rephrase the functions of each tag so that I better understand what each of them does.

@Test – This is a broad tag which simply denotes the presence of a Junit test method to be executed. There are no parameters for this tag.

@ParameterizedTest – This tag specifies that the test being executed must be run multiple times, but with different arguments each time. The test method is defined in the same way it would be under a @Test tag. However, along with the switch to a @ParameterizedTest tag at the beginning of the method, the tag @ValueSource is also used below this initial header. The attributes for this ValueSource tag denote the different arguments to be used and consumed by the test method.

@RepeatedTest – This tag describes a test method being executed a given number of times, specified in the attribute field of the tag. The difference between this tag and the @ParameterizedTest tag is that the same arguments are used for the @RepeatedTest.

@DisplayName – This tag allows the given test method to have a custom display name, which is shown by test reports and during runs. The name (as a string) is the single argument of the tag.

The next few tags affect the order that test methods are executed. Each of them are pretty self-explanatory.

@BeforeEach – With this tag, the specified method will be executed before each of the other test methods.

@AfterEach – Likewise, the method with this tag will be executed after each of the other test methods.

@BeforeAll – This tag denotes a test method being executed first in the order of all of the test methods.

@AfterAll – This tag denotes a method being executed last in the order of all of the test methods.

@Tag – This tag allows filtering or grouping of test methods by adding a custom tag name for its argument.

@Disabled – This tag causes its test method to be skipped.

While there are certainly more annotations in these Junit tests, I’m glad to learn the common tags for further testing in my Software Testing course.



From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Let’s Put It to Rest: What is REST?

We’re preparing for a month-long final project in our Software Design, Construction, and Architecture class, which involves a static web app that utilizes a REST API. We’ve been going over what a REST API entails in some of our lectures, but I also wanted to read more about it so we are more ready for our project to begin. The tutorial that I used can be found at

REST stands for REpresentational State Transfer, and it essentially defines a set of guidelines, or constraints, that a system must follow in order to denote a “scalable, fault-tolerant, and easily extendable system” (from So, a REST API can successfully handle client server requests and subsequent server responses by following 6 guidelines that are part of a RESTful system.

  1. Client-Server – This is associated with the separation between client interface operations and server storage operations without them knowing about each other. This improves scalability of the system and flexibility of the client interface across different platforms.
  2. Stateless – This means that the client and the server can still successfully communicate without taking advantage of any context outside of each request. In other words, both the client and the server do not need any prior requests or responses to still properly complete communications.
  3. Cache-able – Data in a response from the server can be labelled as cache-able or non-cache-able; when cache-able, data from the response can be reused in other requests.
  4. Uniform Interface – This simplifies the architecture of the system by separating its services into independent components: identification of resources (which requires each request to specify which resources, or data, it needs; this is done through the endpoint of a URL), resource manipulation through representation (which ensures that enough information is provided in the request to modify the resources presented), self-descriptive messages (which gives a message to the server that describes how to process the request), and hypermedia as the engine of application state (which provides information about navigating to each resource provided in each response from the server; for example, a link to the localhost may be displayed when returning a response about a local resource).
  5. Layered System – This presents various services of the system in a hierarchical manner so that each component in distinct layers can only see the layers they immediately interact with.
  6. Optional Code on Demand – This optional constraint allows the server to extend functionality of the client by responding with executable code to be run by the client, such as a JavaScript file or Flash application.

This article definitely helped me understand more about how the communication between a local client and a remote server works. I’m very excited for our final project to begin, especially now that I know more about the process behind it!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Composite Design Pattern: What It Is and How To Use It

We just wrapped up a section going over various design patterns used in software, so I wanted to do a bit more research on a different design pattern to get more of an idea about how they work. One pattern that looked interesting was the composite design pattern (, which appeared to combine a couple of concepts that I had seen from taking data structures: inheritance and trees. This structure of the composite design pattern essentially takes on the form of a hierarchy, with 4 types of items: a component, a leaf, a composite, and a client.

The component is the abstract entity in which common behaviors and operations are defined so that repeated code can be prevented. In the example provided in this post, a program to simulate the retrieval of banking information, the “component” expressed a list of other Component objects, methods to add and remove from such list, as well as other abstract and non-abstract methods that can be utilized by other classes extending from the component.

The composite and the leaf (or leaves) both inherit from the component. For this example, the CompositeAccount class served as the composite. This class implements the methods defined as abstract in the Component class. Because the composite and the leaves all inherit from Component, all of these objects from the different classes can be defined as Component objects. Thus, in the CompositeAccount class methods, all of the leaf objects are taken into account by traversing through the list of Component objects. For this example, the DepositAccount and SavingsAccount were leaves, with their own behaviors that were exclusive to the leaves.

Finally, the client puts it all together as the driver for this design pattern. New objects are created in this class, and each individual object is treated appropriately with the correct behaviors (i.e. the DepositAccount and SavingsAccount), while also being part of the bigger system, in this case the CompositeAccount, all of which are underneath the Component umbrella.

This was a great read for me! It was simple enough to understand coming from an extended introduction to design patterns and other programming courses using this kind of structure. I’m currently reading more about the Decorator design pattern for an assignment, so I hope to post more about that soon!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

More About Test-Driven Development

In my last blog post, I briefly mentioned the idea of Test-Driven Development (TDD) as a process for creating programs, as well as its tying-in to Behavior-Driven Development (BDD). I wanted to learn more about TDD, so that will be the topic of this post! The article that I chose to read came from the following website:

This article touched upon concepts presented in both of the software development courses that I am taking (Software Design, Construction, and Architecture; Software QA and Testing). It highlighted the importance of making code that is easily changeable using techniques such as abstraction, encapsulation, or various design patterns. With this kind of coding strategy, developers don’t have to be as concerned about the whole program being affected when a few lines of code are revised. This is associated with more of the software design side of TDD. However, the process by which TDD takes place focuses on software testing, where further code is not written unless the automated and continuous tests produce a failing result. These tests are also written independently of the code being implemented. In other words, the code being tested is considered to be black-box, and the tests are made to uncover the failures in code, from which revisions will be made. This is where changeable code comes into play. This kind of coding mentality strives to ensure that the entire functioning of the program won’t break when the code is changed. This includes the automation of TDD; when the entire program is being rewritten because of a lack of changeable code, this may have additional effects on the testing process.

However, the article is quick to note that while TDD is a way to specify code behaviors by continuously testing and fixing code, it does not replace the process of Quality Assurance. With QA, the potential for code and tests to go wrong, as well as possible ways to navigate around these problems, are all considered. TDD is more “implementation-independent,” where the tests being run are not to assess the way behaviors are implemented in code, but in a more general sense, to simply express the behaviors that the program aims to implement. TDD, in a way, shows the specifications of a given program, and with continuous testing, can exploit the holes in a program so that they can be further improved.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

What is Behavior-Driven Development?

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: This blog post is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. The BDD of tests becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Testing Efficacy and Machine Learning

As stated in the title of this post, this week’s Software Testing topic of discussion relates to the hand-in-hand incorporation of software testing and machine learning, found at the following blog post: Google has been taking on automated testing of their code before permanently committing to their huge repository. By doing so, they have examined “Efficacy Presubmit,” which uses the idea of automatically predicting which tests would be best appropriate to run, as well as learning about which tests are more useful or valuable than others in terms of discovering critical issues in code. Tests that are more guaranteed to pass every time are less meaningful than those that come up with failures. This process of discovering the more valuable tests would certainly assist with optimizing time and resources spent to run tests. To do this, Google applied a machine learning concept, binary classification, to “learn” whether a test would or would not pass (a binary outcome), using the numerical data given from running software tests, such as pass/failure history and runtime for tests. By predicting the outcomes ahead of time, testers can understand which tests are more likely to keep passing every time or produce more failures.

I was really interested in learning more about the software development process at Google. Many of my CS friends discuss how awesome it would be to work at Google, Microsoft, or Facebook, among other giant companies dominating the field of software development. Reading more about how developers at Google undergo the cycle of writing and testing their code (with multiple iterations before and after committing, as to be expected) increased my confidence that even within the first few weeks of my software testing course, our course content lines up with what Google (and other companies I’m sure) is doing. I also enjoyed learning about how machine learning can be applied to software testing. I had only thought of the two concepts in a mutually exclusive fashion, but the description of the data used for the classification of the tests (like the runtimes for tests) gave me perspective of how various concepts in computer science can work together to solve problems.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Let’s Also Talk about Software Construction, Design, and Architecture!

I will also be posting about ideas being discussed in the area of software construction, design, and architecture! I’m looking forward to understanding more about these topics so that I know more about the field of software development without going into it blind. Stay tuned!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Hi, Let’s Talk about Software Quality Assurance and Testing!

This page will be the home of several blog posts related to topics within the broader subject of Software Quality Assurance and Testing! From reading other blogs and listening to podcasts about these topics, I hope to learn more about the exciting developments in this field.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.