This post will discuss more bad practices when coding that focus less on design patterns (post about anti-patterns here: https://kathleenmlaw.com/2018/12/03/some-software-development-anti-patterns/) but more so on problems in source code that may cause a bigger problem in the program, called code smells (reference found here: https://sourcemaking.com/refactoring/smells).

The most common code smells can be grouped into several categories. I have included 3 examples of each code smell that can arise, though there are other

• Bloaters – code (like classes or methods) that grows so large that it is difficult to work with
  • Long methods – methods longer than 10 lines are probably too long
  • Primitive obsession – use of lots of primitives in code rather than creating smaller objects, or many different constants
  • Long parameter list – more than 3 or 4 parameters used when calling a method
• Object-orientation abusers – code that incorrectly implements object-oriented concepts
  • Switch statements – switch statement has many cases, or conditional has multiple “if” branches in a row
  • Temporary field – only have a value when needed by objects in the program, and are otherwise empty
  • Alternative classes with different interfaces – two classes with the same function but only differ in method names
• Change preventers – code that, when changed in one spot, requires change in other parts of the code as well
  • Divergent change – changing many methods that are unrelated when making change to a class
  • Shotgun surgery – when making any changes to code, the developer has to make many other modifications to different classes
  • Parallel inheritance hierarchies – when creating subclasses, the developer has to create subclasses for other classes at the same time
• Dispensables – unnecessary code that would increase readability when removed from the program
  • Comments – when code is full of comments that it is difficult to even read the program
  • Lazy class – a class that doesn’t really have much function in the overall program
  • Data class – a class that only has fields and accessor/mutator methods and serves as a data collector for other classes to use
• Coupling – code that contributes to coupling (where one section of code may depend heavily on another section, and changes in the former results in forced changes in the latter)
  • Feature envy – when a method accesses data of another object more than its own
  • Inappropriate intimacy – when one class uses internal fields of another class
  • Message chains – when one method calls another, which calls another….

I have absolutely made several of these mistakes in my programs, so I’ll be sure to keep a look-out when coding in the future.

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.

When I thought of the word “mutation,” I tend to think of it with negative connotation as something that changes internal structure and can potentially cause problems with the structure later on. However, in software testing, mutations have a positive function. This post will go over how mutation testing works, and some advantages and disadvantages of using it. My reference can be found here: https://www.guru99.com/mutation-testing.html. When going over mutation testing during lecture, I found the subject very interesting, and this website provided great further information about it.

Mutation testing takes a program and changes around various statements (introducing faults) in the source code, so that when running unit testing or other testing suites on the program, the tests written for the original program should fail, if they had already passed before. So, when the mutant program fails the test case, then the mutation is “killed.” If the mutant program still passes the test case, then the mutant “survives,” and the tests should be written differently so that they not only pass the code that is originally written, but they also fail other possible scenarios, whether or not those other scenarios were explicitly written in the program.

There are many different kinds of mutations that can be created and used, and they fall under 3 categories: operand replacement operators (which replaces operands in an expression with another operand or with a constant value, like changing x > y to x > 5), expression modification operators (which modifies an operator in an expression, like changing x > y to x <= y), and statement modification operators (which modifies the logic of the program by changing or deleting different statements, like removing an “else” branch of an if-else conditional).

This method of testing provides several advantages. It can uncover missing test cases that weren’t already included in the test suite. It also points out the different places in source code which may be vulnerable to error. It looks beyond simply statement and branch coverage to find any faults which may be overlooked. This enhances the quality of software testing taking place on the program.

However, there are still some disadvantages of using this testing strategy. Because there are many places in source code where these mutations may take place, it would be tedious to manually insert the faults, and automation is a necessity. Time may also become an issue, because each mutation requires a run through the test suite. Finally, this method would not be appropriate for black-box testing, as it involves directly examining the source code.

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

During one of our final Software Testing lectures last week, we were able to participate in a code review, examining and critiquing a given program. I really enjoyed taking part in this activity, because it helped me understand the program on a deeper level. After all, I wouldn’t really be able to spot any places to improve without first knowing what each line of the program was doing!

For this blog post I wanted to take a look at different code review strategies, as well as any advantages or disadvantages that may arise when using this method of software testing. I was reading these posts for more information: https://smartbear.com/learn/code-review/what-is-code-review/ and https://smartbear.com/blog/collaborate/pros-and-cons-of-code-review-methods-infographic/.

Code review is what it sounds like. Team members work together to review written code and notice areas of possible improvement. There are different ways to go about this process, each of which having their own unique advantages and consequences. The articles that I read listed 5 strategies, and they are described as follows:

• The Email Thread – For this method, a file in need of reviewing is sent to every team member taking part in the code review. This can be helpful when it is difficult to find time in everyone’s schedules to meet. However, long email threads can get complicated for the developers to look through.
• Pair Programming – For this method of programming, developers sit side-by-side and work on the same code together. This method is great to incorporate code review into the development process but may provide some bias due to emotional connections to the work put in.
• Meeting-Based – For this method, smaller groups of reviewers meet with printouts of code or code on a projector. Then, they examine, line-by-line, any issues or problems with the program. While this is a very in-depth approach, this also takes a lot of time. Additionally, some development teams are stationed across the world from each other.
• Over-the-Shoulder – This informal method simply entails another developer standing over the shoulder to the author of the program, as the author walks through each change to the code. This is great for in-person collaboration, but there aren’t really any standardized metrics involved in this method. There is also no traceability to the conversation later.
• Tool-Assisted – This method involves an external tool (whether browser or IDE based) used by the team to successfully review code while also solving some of the issues above, like keeping track of online comments, noting any change in code, and enforcing any standardized metrics. However, some tools may be costly, or may not fit as easily into the workflow of the development team.

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

As I mentioned in a previous blog post, we have been working on a final project in our Software Design, Construction, and Architecture class, where we are constructing a single-page website that connects front-end and back-end components. I’ve been working on front-end elements most recently, and I got up close and personal with Angular structural directives (after debugging my code for almost 2 days). This link was my main reference when trying to fix my code: https://angular.io/guide/structural-directives.

Structural directives, like the name suggests, alter the structure of the HTML layout by changing individual elements in the document. The directive is simply added to the tag of the element to be altered, called the host element. Any descendants of this element will also be affected by the directive. For example, a tag with an ngIf directive would look something like: <div *ngIf=”true”>Hello there! (I didn’t add the ending div tag because this makes the whole tag disappear upon publishing this post)

There are three common directives used in HTML: ngIf, ngFor, and ngSwitch. ngIf takes in a Boolean expression as a string and displays the host element if the expression is true. For example, if the example tag from above was present in a document, the element would still display, and “Hello there!” would be visible.

ngFor is used as a repeater directive, where items in a list or array can be displayed by iteration, or a statement can be shown a certain number of times depending on however many iterations. The loop takes on Python syntax when expressed as a String for the ngFor directive. An example of ngFor would be: <p *ngFor = “let name of names”> This is a name.</p> The loop would iterate the same number of times as the number of names present in the list, and the statement would be displayed that many times as well.

Finally, ngSwitch operates like the switch statement in Java, where one variable’s value is checked, and depending on the value of that variable, one case will be executed, which is an element defined with that variable’s desired value. For example, if you’re trying to look up profiles for different users of a social media website, ngSwitch would work along the following lines: a profile variable would be set to whichever profile name you’d like to look at, and depending on the value you chose, that appropriate profile page would display.

This article was incredibly helpful for me to figure out how to conditionally display some of the elements on my webpage, and I am certain that I will use it later on for further reference!

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

I have heard the term “agile testing” thrown around many times in my classes and other conversations about software development, but I’ve never really known about what it means. When I was writing my blog post about the Scrum process (post found here: https://kathleenmlaw.com/2018/12/03/scrum-isnt-an-acronym-but-what-does-it-mean/), the term came up as well. Obviously, it’s pretty clear that agile testing is very important to software development. I did some reading about what agile testing entails, and found a couple of links which helped me understand more about its significance: https://www.tutorialspoint.com/software_testing_dictionary/agile_testing.htm and https://reqtest.com/testing-blog/agile-testing-principles-methods-advantages/.

Essentially, agile testing is an iterative process of collaborating between end users, the development team, and the testing team. Project development is based on the needs of the customer or the testers. Agile testing is a continuous process which begins at the start of a project or project sprint and remains throughout the course of project development, rather than just happening once as a “testing phase.” This makes the agile testing process more unstructured. Because testing occurs throughout the entire project, rather than just at the end, any errors that come up during development can be fixed at any time.

The amount of communication between all parties is also very high, with testers and developers working closely together to come up with project solutions that fit not only customer specifications, but also testing requirements. Because all parties (including the developers and end users) test the product along with the testers, there is decreased time waiting for feedback and ongoing discussions about how the project is going. Most importantly, every member is on the same page with each step of development.

There are several methods of agile testing that can be utilized during the agile development process: Behavior Driven Development (BDD), where development and testing is based on desired behavior of the program; Test Driven Development (TDD), where the tests to be passed drive the development process, and exploratory testing, where testers explore the program to be tested and then write tests based on what they find.

Here is more information on BDD and TDD, respectively: https://kathleenmlaw.com/2018/10/05/what-is-behavior-driven-development/ and https://kathleenmlaw.com/2018/10/12/more-about-test-driven-development/.

Some of the many advantages of implementing an agile testing environment include the incorporation of all members in the development process, the regular and consistent feedback received from all parties, and the flexibility that comes with continuous, synchronous work on development and testing.

I definitely feel more in-the-know now that I have done more reading about what agile development and testing entail. Now that I’m almost done with my undergraduate career, I’m excited to put these new skills to action in the workplace.

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

Throughout the semester, we have been learning a lot about good coding practice, which includes the implementation of various software design patterns. While we can try our best to fit our code into these design patterns, oftentimes this is not the case, at least for me. So, here is a list of several software design “anti-patterns,” or bad-practice patterns. My good pal James Blash (found at www.jwblash.com) gave me the idea to look more at these anti-patterns. The link that he recommended is https://sourcemaking.com/antipatterns/software-development-antipatterns.

This list has several great examples of different ways that code falls into more of bad practice. Here is a brief overview of some of the interesting design pattern problems that I found from this list.

• Cut-And-Paste Programming – This anti-pattern involves the reuse of existing source code, rather than programming new code from scratch. This can result in multiple errors of similar nature, as errors from the existing code can affect the rest of the program when pasted elsewhere. A fix to this problem utilizes more of a black-box reuse development process, such that the issue of reusing buggy code is more likely to be bypassed.
• Input Kludge – This anti-pattern occurs when behavioral testing fails because software accepting free text input uses “ad hoc” algorithms, which does not account for illegal statements or combinations of characters (e.g. strings when the input only accepts numbers, etc.). Solutions include the use of free parsing software or simply examining and possibly revising the algorithms to account for and properly handle “input kludge” being entered into the system.
• Golden Hammer – This anti-pattern occurs when developers use sort of a “one-size-fits-all” approach to coding; in other words, they take advantage of one or a couple of solutions to attempt to solve all other issues in their programs. A solution to this problem involves further education or training for team members to learn more about other ways to solve problems that arise, rather than just sticking to one familiar concept.
• Poltergeist – This anti-pattern uses poltergeists, or classes with very limited use throughout the program, but can potentially break the whole system when it isn’t there. Often, poltergeist classes start other processes taking place in the program. The solution reorganizes the class structure such that longer-lived objects in the program take on the responsibilities that the poltergeist(s) handled, thus removing the need for the poltergeist classes altogether.

Hopefully with this new information in mind, I hope to try to avoid some of these issues later in my classes, as well as my career!

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

In class, we have started to look at mocking and how to implement this technique in our unit testing. I was pretty confused about how mocking worked, so I wanted to do more research on it this week. This  link has simple explanations of the premise of mocking, as well as other short, yet effective, examples of mocking: https://javacodehouse.com/blog/mockito-tutorial/ .

So what is mocking? In unit testing, we evaluate the functions of different classes and methods within those classes. These methods depend on outside classes, or dependencies, in order to function properly.

But what if the code for those other classes isn’t completed yet? Or, what if there are errors lodged in our dependencies, causing our methods being tested to fail? We still want to ensure that our methods are working properly, without depending on other classes’ behavior.

Mocking can be implemented here. Mocking simulates these dependencies to keep our tested methods independent. As shown in the picture below, the mocks eliminate the need for other classes or dependencies coming from outside of the methods that we want tested.

Image from https://medium.com/@piraveenaparalogarajah/what-is-mocking-in-testing-d4b0f2dbe20a

There are several mocking frameworks out there, including Mockito and PowerMock. We used Mockito in class, so I will be going over that framework more in this post, even though both have the same function.

First, we need to initialize our mocks. Our class did this differently than what is explained in this article, which shows the annotation @Mock for the classes that we want mocked at the beginning of the unit testing, and then using the following statement in our setup: MockitoAnnotations.initMocks(this).

Now that this is set up, we can start performing our testing! Two functions that we used extensively are the “when” “then” pattern, and the “verify” method. The “when” part of the “when-then” pattern passes in a function that requires use of the mocked class and returns a “stub” of the type to be returned from our mocked method. “Then” shows what is expected to be returned after completing our mocked method. “Then” methods can include “thenReturn(returnValue)” or “thenThrow(exceptions)” for different outcomes from the mocked method.

The “verify” method comes in handy when testing void methods. Because we aren’t returning anything, “verify” lets us examine, for example, if the void method is only being called once, that the correct method is being called, or that other void methods are being called instead of the one we want.

Reading this article was really eye-opening into the many different ways that mocking and Mockito can come into play, and I hope to work more hands-on with it in the future to learn even more about how it works.

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

I’ve always been interested in the Scrum project management process, especially because we will be diving into it during my Software Development Capstone class next semester. I found a great link detailing the general methodology of Scrum, as well as specifying the roles of each party involved in the process: http://www.mountaingoatsoftware.com/agile/scrum .

Scrum is essentially a project management technique which consists of the completion of work through multiple shorter periods of progress, called sprints, towards the overall project goal. Before going over the overview of the Scrum process, there are 3 primary parties taking part in Scrum to be discussed: the software development team itself, the ScrumMaster, and the product owner. The software development team is a “self-organizing, cross-functional” group. The team does not have a leader amongst the group who delegates tasks and provides feedback. Rather, all of this is decided by the whole team. Each member of the team is also needed to develop each part of the project, from coming up with ideas, to developing solutions and features to satisfy goals of each sprint. This team has support from the ScrumMaster, who coaches the software team to perform Scrum at their best without telling the team exactly what to do, and the product owner, who serves in more of an end-user role and guides the team towards building the product best fit for the customers.

The Scrum process involves several sprints (commonly 2 weeks long). A planning meeting kicks off each sprint, where all parties create a list of tasks to finish by the end of the sprint, called the sprint backlog. A product backlog is also maintained and prioritized by the product owner, which details additional features to be added to the product and which features are most important to complete first.

Other meetings taking place during the Scrum process include daily Scrum meetings, around 15 minutes long, where the development team goes over what they’ve completed the prior day and what they intend to currently work on. The sprint review at the end of the sprint allows the development team to showcase their product, as well as the product owner to identify places to continue work for the next sprint. Finally, the sprint retrospective at the end of each sprint gives time for reflection of the Scrum process from the just-completed sprint and what needs to improve.

Reading more about this process has gotten me more excited about what is to come in the Capstone class next semester! This is such a great opportunity to take part in, especially while still an undergraduate student.

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

When I was reading about REST APIs, the acronym SOAP kept coming up. In this blog post, I wanted to learn more about what SOAP means and how it compares to what I’ve already learned about REST. The article that I am pulling information from, https://smartbear.com/blog/test-and-monitor/understanding-soap-and-rest-basics/, is a thorough resource, detailing features of each service and how each can be considered “better” than the other.

SOAP (Simple Object Access Protocol) uses XML, a language like HTML, to send requests to a server and receive responses. SOAP was designed to be extensible, with multiple acronyms coming with it to support different usages of the services, such as “WS-Security” or “WS-Coordination.” However, when using free, public web services, these extensions may not be necessary to come into play; it is simply convenient to provide extra functions if needed.

One potentially problematic feature of using SOAP has to do with the entry of XML for requests. Because the complexity of XML code to make requests, some programming languages have built-in support to handle such requests. However, some are not as forgiving and require manual building of the XML code. While SOAP has error handling (which helps to identify where the request went wrong, as well as potentially automate fixing such errors using standardized codes), it is still intolerant to errors caused from incorrectly building the XML. REST has more of an advantage here, because of its reduced difficulty when creating requests; instead of having to program an entire XML file (depending on whichever language you use), REST just uses requests through the URL. This results in faster performance with REST.

With this in mind, though, SOAP does provide other advantages. Coming with built-in error handling is certainly a leg up from REST, along with flexibility of services with other extensions that have different functions. While REST focuses more on quick performance and a lack of complexity, SOAP increases functionality and handles errors effectively.

It is also important to note that unless a developer is making their own Web service, most free and public Web services make it clear which access protocol they use, whether it is SOAP or REST. Even if the Web Service that I access for my final project already has a defined access protocol (which is REST), I am glad to understand more about other options out there for different services available.

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

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: https://www.testingexcellence.com/junit-5-annotations/.

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&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.