In this week’s blog post, I will discuss the article “The Different Types of Software Testing” by Sten Pittet. This article discusses different kinds of tests, some differences between manual and automatic testing, and how to automate testing. I chose this article because it fits well with the software testing section of the syllabus. I also liked how the author went into great detail about the tests mentioned in the article. In this blog post, I will discuss some of the software testing methods in the article.

The first test discussed in the article is the unit test. “Unit tests are very low level and close to the source of an application. They consist in testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.” From what is mentioned in the article, unit tests appear to be immensely helpful in testing smaller pieces of a program. Due to their ease of automation, they could also be beneficial for parts of a program that occur often. The following tests discussed in the article are integration tests.

Integration tests are imperative to ensure different parts of your program function well together. “Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.” While these tests are very helpful, due to requiring multiple systems to be running simultaneously, this type of test can be very costly to run regularly. The next test that I will discuss is the functional test.

Functional tests are very different from the prior two tests I have discussed, wherein the first two tests check the functionality of sections of your project. In contrast, available tests explicitly check for the project’s output. “Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.” This test is beneficial for the business application of a project. In contrast, the project’s pieces must function for the customer, and the project as a whole must also do what it was designed to do, and functional tests are great for determining this.

Article: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s class, we delved into some intriguing topics that shed light on the dynamic world of project management and software development. So, let’s recap the highlights of our recent discussions.

New Project Initiation:

We kicked things off by exploring the essential steps in new project initiation. It all begins with reading product descriptions and commencing a basic requirements analysis. This initial phase sets the tone for the entire project, as it helps us understand what we’re about to embark on. Clarity at this stage is paramount.

Then, we moved on to the technical side of things by creating a new project on GitLab. We ensured that all the required files were in place and established a board structure tailored to support Scrum development. This pivotal step lays the foundation for collaborative, agile work and efficient progress tracking.

One concept that stood out this week was the “Definition of Done.” Understanding and defining what constitutes a complete task is vital to maintaining project integrity and ensuring that everyone is on the same page regarding project expectations.

Copyright and Licensing:

The second part of our class dived into the complex yet critical world of copyright and licensing. It’s not just about legalese; it’s about safeguarding your work and respecting the intellectual property of others.

We explored Free & Open Source Software Licensing, digging into the details of when a work becomes copyrighted and who owns that copyright. This knowledge is essential in avoiding potential legal pitfalls.

We also examined what you can and cannot do with unlicensed software. Knowing the boundaries here is crucial in preventing unintentional violations.

Licensing became a central theme in our discussions, as we explained its role and its significance in the realm of open-source software. We even delved into specific licenses like the GNU General Public License, Mozilla Public License, Eclipse Public License, and MOT License, each with its unique implications and considerations.

Lastly, we explored the importance of identifying the license of published software. It’s essential to be aware of the rules and limitations when using or contributing to open-source projects.

In summary, this week was an exciting journey through the early stages of project initiation, all the way to the intricate world of copyright and licensing. These insights will undoubtedly prove invaluable as we continue our education and venture into the realms of project management and software development. Stay tuned for more exciting insights in the coming weeks!

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog is “Understanding Software Licensing”. This blog discusses what a software license is, how it works, why it matters, a few types of software licenses, and how to decide the best type of license for your software. In class, we discussed the topics that were brought up in this blog so I decided to do a deeper dive into software licenses to refresh my mind on the information that we reviewed and possibly gain a better understanding of it. 

The author tackles the topic in an organized manner that makes each part easy to follow. In the section about why software licenses matter, the author outlines clear advantages from different standpoints. For example, he states that from a developer standpoint, they offer benefits like “preventing users from performing actions like copying and distributing your software, if the license prohibits it, limiting your own liability, spelling out your own rights as a developer, and allowing you to control the usage of your product”. He then outlines the benefits from a user’s standpoint; he mentions that it helps you manage your tools and resources,  prevents you from paying for tools that aren’t necessary for your business, and clarifies how the provider can use your private information. The choice to clearly outline the advantages from each standpoint aids in the reader’s understanding of the importance of licensing software.

The sections on the types of licenses were beneficial. The public domain license is a simple license to understand. The section that defines a copyleft license is an open-source license meaning that deviation of the code must have the same terms. Defining the GNU license as a weak copyleft license helped to simplify what it was. His explanation of a permissive license was helpful as well. He defined each type of license with a short, simple statement at the beginning and then went on to further explain them.

The other part of the article that I found to be very helpful is the section about how to figure out what the best type of license is for your software. Because software licensing is new to me, I was struggling to pick which license I should use for a project. The author mentions that you should “consider the different models, thinking about the purpose behind your code and what you want users to be able — and not be able — to do with it”. It can be very challenging to outline the true purpose of your code clearly. It was very helpful that the author clearly defined the types of licenses in simple terms and then gave simple advice on how to pick which one to use. I enjoyed reading this blog and will use the knowledge for my future projects.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

API, or application programming interface, is a set of specifications that allow applications to interact with one another. They enable transfer of information and is treated as an intermediary level let companies open their application data to external third-party developers as well as internal departments within the company. An example of how APIs work is third-party payment processing. For instance, when making a payment online and being given an option to “Pay with PayPal”, the connection made between the third-party payment system and the website where the payment is being made is reliant on APIs. When selecting the option, an API calls to retrieve information or request. After processing the request from the application to the web server, the API makes a call to the external program/web server. In this situation, it would be the third-party payment system. The external system then sends the requested information back through the API to transfer to the initial requesting web server.

REST is a set of design principles and stands for “representational state transfer” architectural style. Sometimes referred to as RESTful APIs, they were first defined in 2000 by Dr. Roy Fielding and provides more flexibility and freedom for developers. They can support many different data formats and are required to follow the 6 principles, also known as architectural constraints. The six principles are the following: uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture, and code on demand (optional).

Uniform interface means that all API requests from the same resource should have identical formats to ensure that a piece of data belongs to only one uniform resource identifier (URI). The resource should not be too large while still containing the information the client needs. Client and server applications must be completely independent of each other in REST API design. The client application only needs to know the URI of the requested resource and cannot interact with the server in any other ways. Statelessness means that each request needs to include all the information necessary for processing it, which means REST APIs do not require any server-side sessions. Resources should be cacheable on the client or server side and the server responses should contain the needed information about whether caching is allowed for the delivered resource. The purpose of this is to improve performance on the client side while also increasing scalability on the server side. REST APIs have different layers to them that calls and responses go through. To note, do not always assume the client and server applications connect directly to each other. These APIs need to be designed so that neither the client nor the server can tell whether it communicates with an intermediary or end application. In certain cases, responses can contain executable code when they usually send static resources. In the case that an executable code is added (such as Java applets), the code should only run on-demand.

What is a REST API? | IBM

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Overview

In order to be able to use someone else’s software for your own software project, you must attain a software license. This license establishes the rights and limitations that you have when using the product owner’s software. Software licenses are attained by licensing agreements, where you sign a contract with the owner of the software to use the patented technology.In that contract contain the rights, responsibilities, and limitations you have as a user. I think if you develop some sort of software, it is crucial that you and your team are recognized as the owners of it, and that outside users don’t use it however they feel like. There are many types of software licenses that have different terms and conditions. An article that I read by Ben Lutkevich went more into depth of what a software license and agreement will usually look like, as well as the different types.

Attaining a License

You are about to sign the licensing agreement to officially be able to use someone else’s software. Here’s what to expect. On it will be basic information about both sides. Your name, your address, contact information, as well as the lending party’s. It will contain when the agreement officially goes into effect, and you are able to use the software. It will contain the duration of how long you are able to use the software. It will include how much you have to pay for the software, how many users are eligible. It will give a disclaimer of warranties, as well as maintenance, upgrades and support. Most importantly, it will include the permissions and limitations on distributing the software, user rights of copying and modifying the software. These licensing agreements may differ depending on the type of software license.

Types of Software Licenses

The most common software licenses you find are Proprietary and FOSS. A proprietary software license is commonly referred to as closed-source. Proprietary licenses do not allow users to freely alter the software. Whereas FOSS (Free and Open-Source Software) is the opposite, where the customer is allowed to use the source code and alter the software. FOSS is commonly referred to as open-source. This is the type of license that we will be using in class. Two other licenses that are familiar are Permissive and Copyleft. Permissive software licenses establish some requirements for distribution or modification of the software, and Copyleft notes that licensed code may be distributed or modified as part of a software application or project if all code involved is distributed under the same license. New products containing old code with a copyleft license have the same restrictions as the old code’s license.

Conclusion

If planning to create a software product, it is a smart idea to establish copyright for it, so you are credited for the work you put in. And if you are using someone else’s product for your own product or project, it is the smart decision to attain a licensing agreement, avoiding any potential lawsuits.

Article URL

https://www.techtarget.com/searchcio/definition/software-license#:~:text=A%20software%20license%20is%20a,the%20software%20without%20violating%20copyrights.

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

This week, I wanted to continue writing about the SOLID software design principles. The next principle I have to cover is the Liskov substitution principle. This principle expands upon the Open/Closed principle I wrote about the previous week, providing a guideline on how a superclass and its child classes should behave.

This principle was first defined by Barbara Liskov in 1987, and later adopted by Robert C. Martin. From a paper that Barbara Liskov cowrote with Jeanette Wing, they defined the Liskov substitution principle as a mathematical property: “Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.”

Translated into plain English, this principle states that instances of a superclass in a program should be able to be replaced by one of its subclasses without breaking the program. Overridden methods from a subclass must accept the same input as the superclass’s original method, and the return value of a subclass’s method must be able to be used the same way as the value returned by a superclass’s original method.

Creating code that abides by this principle isn’t simple, as the compiler can only verify that the structure of your code is correct, not that any specific behavior of your code always executes when desired. Creating robust test classes and cases is the best way to check if your code is following the Liskov substitution principle, checking portions of your program using all subclasses of a particular component to ensure there are no resulting errors or loss in performance.

The author of this article series has included another code example representing a coffee machine to illustrate this design principle, as they have done in their previous articles. They present the problem of creating different subclasses of coffee machines from a generic parent class, with two classes with an “addCoffee()” method that accepts two different types of objects, CoffeeBean and GroundCoffee. The author suggests two solutions, either creating a common Coffee class that can be utilized by both the BasicCoffeeMachine class and the PremiumCoffeeMachine class, or create a common implementation of a “brewCoffee()” method that also appears in both CoffeeMachine classes. The first solution would violate the Liskov substitution principle, because each CoffeeMachine class would need to validate that they are receiving the correct input type for the addCoffee() method, as the BasicCoffeeMachine class can only use the GroundCoffee type, and not the CoffeeBean type. The author’s preferred solution is to remove the addCoffee() method from both CoffeeMachine classes and implement a common brewCoffee() method in the CoffeeMachine interface implemented by BasicCoffeeMachine and PremiumCoffeeMachine. Since all CoffeeMachines are expected to brew filtered coffee grounds, this brewCoffee() method should have that responsibility.

I want to further understand this principle because in a past project, I made a simple video game that used lots of objects of different subtypes that inherited from a single GameObject parent class. If I want to return to that project, or begin a similar one in the future, I want to make sure that I am not losing any functionality as I design and implement subclasses of a broader parent class.

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

SOLID Design Principles

SOLID is a subcategory of five principles, the first being:

Single Responsibility Principle (SRP)

SRP states that a class, module, or function should only have a singular function.

For example, having a class ‘Animal’ with methods ‘displayAnimalName()’, ‘animalSound()’, ‘feedAnimal()’ would be a violation of SRP because each method has a different function. Creating three separate classes that would each represent a functionality resolves the violation. This entails new classes are created for DisplayName, Sound, and Feeding. Although this may lead to more code overall, having separate classes allows for better maintainability. Without SRP, making changes to one functionality may break another.

Open-Closed Principle (OCP)

OCP states that code should be open for extension, but closed for modification. Therefore the code’s behavior should be extended by adding more code rather than modifying the existing code.

Function ‘getArea()’ calculates the area of a shape using a switch statement where there are cases for a square and circle. To add another shape, the switch statement must be modified to add a case for the new shape, violating OCP. To satisfy OCP, one would create separate classes for each shape that implements the Area interface. Now to add a new shape, one would add a new class and implement the Area interface rather than modify the original switch statement.

Liskov Substitution Principle (LSP)

LSP states that child class objects must be substitutable with objects of the parent class without affecting the correctness of the code.

Imagine a parent class ‘Bird’ with method ‘fly()’, and child classes ‘Penguin’ and ‘Eagle’. Both inherit ‘fly()’ because ‘Penguin’ and ‘Eagle’ are child classes of ‘Bird’. Because penguins cannot fly, the ‘fly()’ method in ‘Penguin’ has been overridden to do nothing. Doing this would violate LSP because objects of ‘Penguin’ would not be substitutable for objects of ‘Bird’.

Interface Segregation Principle (ISP)

ISP states that users should not be forced to implement interfaces they will not use.

Imagine an interface ‘Worker’ that has methods ‘work()’ and ‘eatOfficeLunch()’. Classes ‘FieldWorker’ and ‘OfficeWorker’ both implement the ‘Worker’ interface. Because ‘FieldWorker’ does not eat in office, the method ‘eatOfficeLunch()’ is unnecessary. This violates ISP because ‘FieldWorker’ is forced to implement ‘eatOfficeLunch()’ although the method will not be used.

Dependency Inversion Principle (DIP)

DIP states that high-level modules should not depend on low-level modules, keeping that as separate as possible.

For example, there’s a project with high-level systems (backend logic), that relies on low-level modules (database access). However the project’s team wants to change the database from one type to a different. Because the high-level systems are specifically written and depend on the database type, they would no longer work once the database type changes. Having high-level systems be more abstract and able to be implemented in different ways is ideal.

Conclusion

The article used was chosen because it gave examples with code, making understanding easy. As someone who wishes to have a career in software development, knowing the best practices for designing maintainable code is crucial. I expect to apply these principles to all future projects.

Resources:

https://www.freecodecamp.org/news/solid-design-principles-in-software-development/

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