For this week’s blog post, I decided to find a blog post on a topic that we haven’t explicitly covered in class. I found an article on Agile Testing and my interest in Agile as a whole drew me in. This article is on QASymphony and breaks down what Agile methodology is, some examples of Agile testing, and how to align testing with the Agile delivery process. For the sake of this post, I will assume you’re familiar with the general concept of the Agile methodology for software development, hopefully you understand the general concept of Scrum and Kanban.

One of the interesting testing strategies for Agile development is the Behavior Driven Development tests (BDD). These tests are similar to the Test Driven Development (TDD) style testing systems in traditional waterfall development cycles. They are basically a replacement. Instead of writing unit tests before code is written, the BDD tests are on a much higher level. This is how user stories are written. The development of the code is based on end-user behavior and the tests need to be readable for those who might not be particularly technical as they can often replace requirement documentation. This saves time in the long run as there is no duplication of the process for those who might not be able to read user tests in the traditional TDD style of testing. The best part about BDD testing is that the tests do not necessarily need to be written by technical team members. These can, and are often written with input from business partners, scrum masters, and product owners who might not necessarily be able to contribute when it comes to writing unit tests in the TDD format. This style also allows for testing small snippets of functionality like TDD so that one aspect of TDD that is somewhat Agile remains intact for BDD testing.

After reading through the other testing strategies and how to align testing with the Agile methodology, I realized that I’ve already been working in systems that operate like this at my summer internships. We operated our testing in a format pretty much identical to the concept of BDD where everyone in the team contributed to the different testing obstacles and even came up with test cases that would need to pass by code that was written afterwards. And like the article says, it was common for not all of the tests to pass immediately, and this is part of the concept of “failing fast” that Agile is all about. I am glad I found this article to give me more insight to how businesses around the world, including the ones I interned at, are converting to Agile and utilizing these testing strategies if they haven’t already.

Link to original article: https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to choose a subject that would give me a little more experience with a technique for black box testing, or developing tests for software without direct access for the code for a particular application. This way, the tests are created with a bigger focus on the business logic instead of particular barriers that may arise within a programming language or the overall stack of the application. I found an article on softwaretestingclass.com that covers the usefulness of decision tables in regards to software testing. The article discusses how to use decision tables as well as why they are such an important tool for black box testing. The article also mentions other examples of testing techniques for black box testing.

The author, Venktesh Somapalli, provides an example of a financial application where there are two possible conditions for a user, repayment within a term, or moving on to the next term of a loan. Somapalli goes through the steps that a tester may consider constructing a decision table for this particular application. The table for the decision table technique is based on conditions either being true or false, so all outcomes are absolute. This means that there are there should only be one outcome for a set of conditions. However, the reverse of this is not true, there are can be more than one set of conditions that have a particular outcome. In the example in the article, if both of the conditions are true or false, an error message is the outcome. On the other hand, there is only one set of conditions that processes money, and one that processes the loan term.

My favorite part of this testing technique is that it is inherently non technical due to the nature of black box testing and the simplicity of the concept. This means that non technical people within a business can understand and even develop test cases using this technique. As Somapalli points out, this technique is also versatile because it can be applied to any set of business logic. Somapalli also notes that decision tables are iterative meaning that if any new conditions are added to the logic, the existing table can be reused and revised to consider the new logic without a complete reconstruction. I definitely agree with his arguments for the usefulness for this technique. I have used this technique in the past and before reading this article, I didn’t even consider the powerful nature of this versatile strategy. I will definitely continue to make use of this technique when developing test cases whenever possible throughout my career.

Link to the original article: https://www.softwaretestingclass.com/what-is-decision-table-in-software-testing-with-example/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For today’s blog post, I wanted to cover a specific topic that I don’t particularly enjoy. While that may sound counterintuitive, I feel that it is important to repeatedly work on skills, even if they aren’t your favorite to practice. So for today’s post, I found an article on imalittletester.com about using try/catch blocks in testing. I don’t particularly enjoy try/catch blocks even though they are incredibly useful and necessary. The author explains multiple scenarios that may occur with try/catch blocks, ensuring that false positives are avoided. She dives into the scenarios, using pseudocode to illustrate what a method may look like for each scenario, and examines how tests must be constructed for each scenario to test the proper criteria.

One of her examples, the scenario where a test should only pass if an exception is not thrown is probably my favorite. She explains that the try/catch block isn’t really needed in this scenario because if we are testing that an exception is not thrown, code without a try/catch block would fail just the same as the try/catch block. This is one less scenario that I’ll have to use the dreaded try/catch blocks.

In my opinion, the most confusing of the four scenarios is how to write a try/catch block where a test should only pass if the exception is thrown. The author explains that what must be done to ensure your test works properly is to have a marker in the try block that will execute if and only if the code that is supposed to throw the exception, doesn’t throw the exception. When executing this try/catch block, the only time that this marker will execute, is when your test is failing. The author explains this in a way that is clear, and easy to follow even for those of us who have such a dislike for try/catch blocks.

In all honesty, I’m glad that I chose this article. I try (no pun intended) to avoid using try/catch blocks as much as a I can, as they can be confusing to me at times. But like I said in the beginning of this post, it is extremely important to practice skills and possibly even more important to practice skills that you don’t particularly like. I will definitely consider this article the next time I’m forced to incorporate try/catch blocks in a program I am writing.

Link to the original article: https://imalittletester.com/2017/04/24/better-test-code-principles-5-mind-your-trycatches/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.

I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.

Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.

Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.

I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For the last couple of weeks, I’ve revisited a couple of the most important concepts of Object Oriented Programming, Polymorphism and Encapsulation. This is my final post for my CS-343 blog entries, and I have decided to continue in this trend. Today’s topic is Abstraction. This week I’ve gone to a favorite resource of mine, geeksforgeeks. Their article on Abstraction covers almost every question that comes up with Abstraction.

I feel it is best to first specify what an abstract class is, and how to make use of one. In Java, an abstract class is defined with the abstract keyword. An abstract class cannot be directly instantiated because of the abstract methods inside the class. An abstract method, is a method that does not have an implementation but must be present in all children classes. This is done via overriding the method(s) in the children classes. Only one method has to be abstract, meaning that there may be other methods that have complete implementations that are reused in their entirety by children classes. Similar to how we implement an interface, we extend abstract classes.

Like my other blog posts, I feel that the best way to learn a concept, is through examples. More importantly, the examples need to be practical, and ones we can relate to. For abstraction, the article on geeksforgeeks uses the classic Shape example that we’re all familiar with.

Our abstract class is the Shape, with three methods and one variable, or attribute. Each Shape has a color, getColor method and two abstract methods, area and toString. A Shape fits exactly into what an abstract class should have, and shows exactly what we can know, based on the object simply being a Shape. A Shape has to have a color, but the formulas for finding the area are different depending on the type of Shape, and the same goes with the toString method.

The children classes presented in the example are the Circle and the Rectangle. The UML from the original article even shows the extends declarator for the children classes. It’s important to note that the abstract methods are not rewritten in each of the children classes. This is because we have to implement them, and thus, they are carried over when we apply the extends declarator. The only new pieces of information in the UML are the attributes we can use for our abstract methods, radius for Circle, and length and width for Rectangle. As seen in the code blocks below the UML, these are used to calculate the area and then the toString.

Abstraction is one of the most important tools that any object oriented developer must have in their toolbox of concepts. This is used in almost every full scale application and often numerous times throughout. A lack of understanding of abstraction will lead to failure to excel in the software engineering world.

Original post here:

http://www.geeksforgeeks.org/abstraction-in-java-2/

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For my last blog, I revisited the important concept of polymorphism. For this post, I decided to revisit another important concept, encapsulation. I wanted to find a similarly formatted article/blog post to the one I found for polymorphism, but wanted to get a different perspective from a different resource. I wanted a source that still mixes in code examples,

Let’s start with the definition of encapsulation. Encapsulation is the ability to package data and related behaviors, in an object. This also includes the access permissions for the behaviors within the object. Encapsulation is often used a synonym for data hiding, but it’s important to acknowledge that while encapsulation includes data hiding, this isn’t all that encapsulation is. Everyone thinks of encapsulation as the concept of public versus private variable types. The concept of encapsulation does include this concept, but this is only one area that relates to encapsulation. When creating a new class, encapsulation should be a top priority. This is because with encapsulation, maintainability is drastically increased.

To further explain that encapsulation is not only data hiding, the article uses a classic coding example, an animal class. The class contains several attributes (name, type, height, color) and behaviors (hunt, run, mate, getName). Encapsulation is more than just making sure the attributes are private, it is about bundling the attributes and the related behaviors within one class. We could have the hunt, run, mate, and getName behaviors all in separate classes theoretically, but this would just be poor design. The article also notes that encapsulation is not about getters and setters. While these behaviors are related to the attributes, the authors wanted to make sure readers didn’t confuse encapsulation with this concept. Encapsulation does include getters and setters, but they are not the focus, instead we should focus on the behaviors that return a different value depending on the attribute, instead of just returning the attribute or setting a new value for the attribute.

To explain how I would use this in the future, why not explain how I would expand upon the code example used in the article? This code example in the article only includes hunt, run, mate, and getName for behaviors. If we wanted to add a speak functionality to our animal, we would use encapsulation. This might mean adding a new private variable, but also would include adding a new method that depends on an attribute or several. This behavior and additional attribute(s) would be added to our animal class to encapsulate the data and behaviors, and ensure the best maintainability for our codebase.

I found this article to be simple but powerful. It’s easy to forget that encapsulation is more than data hiding. Encapsulation is one of the major concepts of object oriented programming and complete understanding is necessary for success. I’m sure I’ll get interview questions regarding this topic in the future.

The original article: https://javapapers.com/core-java/java-encapsulation/

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Before this class, I had heard of Angular before and had always heard it referred to as a JavaScript framework. I guess technically it is, because it still compiles to JavaScript but the language itself is written in the JavaScript superset, TypeScript. I had never heard of TypeScript before this class and the idea of a superset language was also a new concept. I was curious why Angular was written in TypeScript over JavaScript or other supersets. I know from outside sources that the first iteration of Angular was written in JavaScript but every iteration of the framework since, has been written in TypeScript and I wanted to know why. This post by Victor Savkin lays out the benefits of using TypeScript as a way of explaining why Google chose TypeScript for Angular.

Victor clears up my lack of understanding of what a superset is relatively simply. He explains that being a superset of JavaScript, everything you can do in JavaScript, you can do in TypeScript. With small changes to the code, a “.js” file can be renamed a “.ts” file and compile properly.

Victor emphasizes the lack of scalability in vanilla JavaScript. With JavaScript, large projects are much more difficult to manage for many reasons including the weakly typed aspect and the lack of interfaces. TypeScript solves these problems and helps create better organized code with its syntax. With its better organization, TypeScript is much easier to read through compared to JavaScript.

The lack of interfaces in JavaScript is a major reason why it doesn’t scale well for large projects. Victor uses a code example in JavaScript that shows that aspects of a class can be lost in JavaScript because of its lack of explicitly typed interfaces. The code is then reshown in TypeScript and is much more clear because you can actually see the interface. It’s that simple, in JavaScript, you have to really focus in on how every object interacts with each other because of the lack of explicitly typed interfaces. TypeScript allows you to create these interfaces so future code maintenance is less stressful and bug filled.

TypeScript offers explicit declarations, which is illustrated through some code samples in the article. The JavaScript code is a simple function signature that lacks any typing or clear information about the variables involved in the function. In the TypeScript version, it is clear what the types of the variables are, making the function much more clear in TypeScript.

There are other reasons defined in this article on why TypeScript was chosen and what makes it so great, but these are a few of the ones that stuck out to me. I’ve written JavaScript projects before and wondered how some of these concepts would affect larger projects, and now I know how they can be resolved. This article and information will prove useful for writing my final project and any future TypeScript-based projects that I decide to take on in the future.

Original Post: https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.

This week I found this article on JavaWorld by Jeff Friesen that is entirely about polymorphism. Polymorphism is a core concept for all software development and a lack of strong understand will lead to weak applications and poorly written code. One can never revisit topics like polymorphism too much. This article discussing the four types of polymorphism, upcasting and late binding, abstraction, downcasting, and runtime type identification (RTTI). The article presents everything in the form of a code example and constantly revisits in the explanation process, which I find incredibly useful.

The first part of the article is an overview of the four types of polymorphism, coercion, overloading, parametric and subtype.. Of these four there are some bits that stuck out more to me than others. For coercion the obvious example is when you pass a subclass type to a method’s superclass parameter. At compilation, the subclass object is treated as the superclass to restrict operation. The simple example that is forgotten is when you perform math operations on different “number” data types like int’s and floats. The compiler converts the int’s to float’s for the same reason as the subclass to superclass object. Another piece in this first section that stood out to me was the overloading type of polymorphism. The obvious example here is overloading methods. In a class, you can have different method signatures for the same method name and each will be called depending on the context. Again, there is a simple example that is overlooked in the operators like “+”. For example, this operator can be used to add int’s, float’s, and concatenate Strings depending on the types of the operands.

The upcasting section uses our favorite example, different types of shapes and is almost entirely written in reference to one line of code, Shape s = new Circle(); This upcasts from Circle to Shape. After this happens, the object has no knowledge about the Circle specific methods and only knows about the superclass, Shape methods. When a shared method (implemented in both Shape & Circle), the object is going to use the Shape implementation as well unless it is clear through context to use Circle’s.  Similar to this section that uses superclasses and subclasses, is the section on abstraction. The article uses the Shape and Circle example again but points out that having a draw() method that does something in Shape does not make any sense from a realistic standpoint. Abstraction resolves this, meaning that in an abstract class, there is no way to instantiate a method like draw() for the superclass of Shape. This also means that every abstract superclass needs subclasses to instantiate their behaviors.

These are just a few parts of the article that stood out to me personally. The article as a whole is incredibly useful and worthy of a bookmark by every developer. I will continue to revisit this article if I find myself lacking confidence about the topic of polymorphism in the future!

Original Article: https://www.javaworld.com/article/3033445/learn-java/java-101-polymorphism-in-java.html

From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.