Over the past couple of weeks in our Software Quality Assurance and Testing course, we’ve been working on writing code using Test-Driven-Development as well as coming up with JUnit test cases based on code that was already written. Over this time, I’ve come to notice that naming conventions for test cases can prove to be a little challenging in some situations. This is especially the case when writing tests in a Behavior-Driven-Development (BDD) manor. BDD, I feel, has kind of become the norm when it comes to naming conventions for JUnit tests and what this means is that tests are written specifically to test certain expected behaviors of methods/classes and are named as such. To clarify this, let me give an example using the code we were working on in class; imagine you write a test case that is going to test our readToGraduate() method in our Student class. While you will most likely have multiple test cases for this method, since there are multiple factors to consider when determining if a student is ready to graduate, one of your JUnit tests might test to make sure the method returns false when the student’s LASC and major requirements are complete, and they have obtained enough credits but their GPA is less than 2.0. A possible name for this test, following the BDD practice of naming, might be:

As you can see this is kind of a mouth-full. Even though this describes the behavior we should expect with the given input, the readability of this code is pretty lousy. That’s why I decided to do some research on different naming conventions for naming JUnit test cases for this week’s blog post.

I found a blog post titled, Getting JUnit Test Names Right, written by Frank Appel, a software engineering professional, in which he addresses the same problem I have just described. Essentially what Frank suggests in his blog post is that we keep naming simple, which may mean making our test names less descriptive, and use good naming conventions for methods and variables inside the test case to enhance readability. He explains that test names can be made simple through our test’s name only describing state information. Hence the test case I described earlier may look something like this:

Although the name of this test may apply to multiple tests with different inputs we could address this by simply adding a number at the end of the name for different input values being tested.  Frank, addresses this issue as well in his explanation. He says that although this naming convention may lead to names that could apply to a variety of tests, using good naming conventions inside your test method will clear up some of the vagueness. Also, as Frank points out, since the JUnit reporting view provides pretty descriptive messages when a test fails, this will also help clear up some of the ambiguity.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Flyweight

The blog I chose to talk about this week goes into detail about the flyweight design pattern using its applications and implementations. When the blog starts talking about the applications of the design pattern, it begins with the situations of when you should use this design pattern. It explains that flyweight is centered around memory and sharing which may not be an issue for today’s computers, but it still is prevalent within mobile phones. When there is a need to create many objects, that needs memory power to execute but this design pattern focuses on efficiently optimizing that memory sharing which helps boost performance. The application of this design is shown in the blog when it talks about the large number of objects being used by the system and how flyweight will group certain objects together to reuse code to make the entire problem less repetitive. The blog then goes on to talk about the intrinsic and extrinsic states which is explained through the types of data values the objects can hold. It explains how a concrete object may hold an intrinsic state as a value which allows that value to have certain properties. These properties can be extrinsic and be modified as needed.

I chose this article because as I read more about this flyweight design pattern, I realized it also had the possibility for factory implementation as well due to the efficiency with mass object creation. This really interested me since we just went over factories and I wanted some more experience in understanding how factories can be used in other patterns. Though it would just be used to test this design pattern, I thought it was good exposure to how they worked, and it worked well with explaining how flyweight worked. The content was easy to explain with the examples used that had written out code and UML diagrams. The blog used these resources together with JDK to produce an output based off a test class that emphasized the main points of the applications and implementations. They helped cement the idea of factories and code sharing between different objects very well and used similar concepts to those discussed in class. This would affect my future practice by allowing a new view on code reuse which is an important concept. This pattern taught me more about code efficiency using factories and different pattern concepts as well as the idea of objects having different modifiable properties.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Source: http://codermike.com/starting-c4

Getting Started with C4 by Mike Minutillo on Coder Mike is a blog post introducing the C4 Model. The C4 model is a way of allowing users to communicate and describe software architecture. This model is composed like a software system that is made up of containers, that each have components that are then implemented by classes. Lastly, context which is basically a description of the parts of the system or their relationships between each other. These four, context, containers, components, and classes is what makes up C4. Furthermore, Mike goes in-depth in explaining how it helped his situation from starting from a blank white board. By starting with a context diagram, he is able to map out the different problems of their design and revise it for the next version. This process would be repeated until they are satisfied and can continue down the right path.

Tools are developed over time to solve common issues faced in society today, by not utilizing existing tools provided by to us today would be a waste. Learning about UML Diagrams, would eventually lead into learning C4 Model. This model also utilizes UML diagrams in the classes section for its intended use. The idea of being able to clearly represent and describe parts of a software system like the UML diagrams purpose for classes makes this a worthwhile read. The various models within the model such as System context is extremely valuable to me because it allows me to explain how everything pieces together from a higher-level view.

Much like UML diagrams, the author stated that it your initial diagram doesn’t have to be perfect, it’s going to change over time. The value of being able to show, explain, and revise is much better than time spent working out a grandeur solution. Utilizing the different diagrams will grant a much better time spent on projects certainly when there is no clear starting point like Mike pointed out. First starting with Context diagram will explain what things do and their relationships to each other. Then we can go into the container diagram, where you separate important bits into parts like a database or an app. From there I can then start grouping related functions into components which is then accompanied by classes explained using UML diagrams. These four diagrams will provide a nice guide for myself and group members during implementation and provides proper documentation.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.