This week’s blog topic was chosen simply because I had zero knowledge of the term/topic. Jake Holy’s blog on Stochastic and Property-Based Testing blog covers the uses of each testing and effective tools used to implement each. Stochastic testing refers to the testing method that uses random inputs to test the behavior of the program. Rather than using predetermined inputs for test cases, stochastic utilizes various inputs to find unexpected bugs in the program. The main purpose of stochastic testing is to uncover errors through unorthodox methods. This method offers a wide testing coverage by testing all possible scenarios that might go unnoticed with traditional testing.

Property based testing refers to the method of testing by describing what the software should do rather than creating distinct test cases. Initially, testers establish properties that describes what the code should always do. This method of testing utilizes tools that automatically generate test cases to test these properties. After generating these cases, random inputs are utilized to ensure the properties are followed. The benefit of this testing method is testers are only required to declare the properties the code must follow. Instead of manually creating test cases and risking the possibility of missing a test case, these cases are generated for them. Property based testing guarantees effective test coverage. Additionally, this form of testing allows testers to focus on the abstraction and behavior of their code, allowing for a more robust product.

The blog goes in-depth with various testing tools, for example, a testing library created for the Haskell programming language called QuickCheck, which allows developers to write properties for their code which is automatically generated into test cases. QuickCheck has become a very popular tool to use for testing due to its automation, which is why it has been ported to other programming languages like Python and Scala.

The second tool that the blog mentions is Stimulant for Clojure. Similar to QuickCheck, Stimulant allows developers to define properties and it automatically generates test cases to test your program.

One thing that is mentioned in both testing libraries is shrinking. Shrinking refers to the method of finding the smallest input of a failing case, allowing developers to precisely pinpoint areas in the program that is causing the test case to fail. It is crucial that developers know their program has failed a test case, but it is even more crucial that they know why, so they can effectively fix the problem.

Blog: https://blog.jakubholy.net/2013/06/28/brief-intro-into-randomstochasticprobabilistic-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

PATH TESTING.

Path testing is an approach to testing where you can ensure that every path through a program has been executed at least once. However, testing all paths does not mean that you will find all bugs in a program. There are some steps involved in path coverage testing. Step one is code interpretation. It is important to carefully understand the code you want to test. The next step is constructing a control flow graph. It shows the nodes representing code blocks and edges for the movement of control between them. The third step is determining the paths. This entails following the control’s path from its point of entry to its point of exit while considering all potential branch outcomes. While determining paths, you’ll also consider loops, nested conditions, and recursive calls. It is important to list every route like giving each path a special name or label so you can keep track of which paths have been tested. The next step is testing case design. Create test plans for each path that has been determined, make inputs that will make the program take each path in turn. Make sure the test cases are thorough and cover all potential paths. Examine the test results to confirm all possible paths have been taken. It is important to make sure the code responds as anticipated.

Some advantages of path testing is it helps reduce redundant tests, it focuses on the logic of the programs and it is used in test case design. Some cons of using path testing is the test case increases when the code complexity is increased, it will be difficult to create a test path if the application has a high complexity of code and some test paths may skip some of the conditions in the code. There are three path testing techniques which are Control Flow Graph (CFG) – The Program is converted into Flow graphs by representing the code into nodes, regions, and edges. Decision to Decision path (D-D) – The CFG can be broken into various Decision to Decision paths and then collapsed into individual nodes. Independent (basis) paths- Independent path is a path through a DD-path graph which cannot be reproduced from other paths by other methods. I chose these two resources because they go more in depth about path testing and help explain it well. One of the sources talks about the pros and cons of using path testing, the types of path testing which I didn’t know before this.

References.

https://www.geeksforgeeks.org/path-testing-in-software-engineering

https://www.tutorialspoint.com/software_testing_dictionary/path_testing.htm

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

In the realm of software development, testing is a critical phase that ensures the quality and reliability of the product. This week, my exploration led me to a compelling resource that sheds light on an integral part of testing methodologies: the use of stubs. Stubs are simplified, replaceable components that mimic the behavior of real software modules, allowing testers to isolate and test individual parts of a program. The resource, an insightful article titled “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” provided a comprehensive overview and practical advice that I found particularly enlightening.

The reason I selected this resource was its direct relevance to our current course material on software testing methodologies. As we delve into the complexities of ensuring software reliability, understanding the role of stubs becomes indispensable. This article not only introduces the concept but also illustrates its application with clarity and precision, making it an invaluable tool for beginners and seasoned developers alike.

Upon reading, I was struck by the depth of information presented. The article begins by defining stubs and differentiating them from other testing techniques such as mocks and drivers. It then delves into practical scenarios where stubs can significantly enhance the testing process, such as in unit testing and integration testing. The step-by-step guide on implementing stubs, complete with examples in popular programming languages, was particularly useful.

Reflecting on the content, I realized the importance of stubs in creating a controlled test environment. By simulating specific components, stubs enable testers to pinpoint errors more efficiently and focus on testing the functionality of individual units without the complexity of the entire system. This not only streamlines the testing process but also improves the accuracy of test results.

The application of what I learned from this article to my future practice is clear. I anticipate using stubs to conduct more effective and efficient testing, particularly in complex software systems where isolating components can be challenging. The hands-on examples provided will serve as a reference guide as I implement stubs in my projects.

For those interested in diving deeper into the subject, I highly recommend reading “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” This resource has significantly enhanced my understanding of stubs in software testing and equipped me with practical skills that I look forward to applying in my future endeavors.

Resource Link: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

As we continue to explore the vast landscape of software testing, I am excited to share more discoveries and insights. Stay tuned for more reflections and learning experiences.

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

Summary of the Pattern: “The Deep End” pattern is about deliberately taking on roles or projects that stretch your abilities beyond your current comfort zone. It’s predicated on the idea that significant professional growth often comes from tackling challenges that seem slightly beyond our reach. This pattern encourages individuals to seek out opportunities that demand a rapid acquisition of new skills and adaptation, thereby accelerating their learning curve and enhancing their resilience in the face of complex problems.

My Reaction: Upon first reading about “The Deep End,” I was both excited and intimidated. The idea of purposefully putting oneself in challenging situations as a strategy for growth is as daunting as it is inspiring. This pattern speaks to a deeper truth within professional and personal development: growth is not found in the comfort zone. My reaction is a mix of eagerness to apply this pattern in my own career trajectory and a cautious awareness of the balance required to avoid being overwhelmed by challenges.

Insights and Changes in Perspective: Reflecting on “The Deep End” has led me to reassess my own career path and the opportunities I’ve chosen to pursue. It made me realize that some of my most rewarding experiences came from times when I was out of my depth, forced to learn, adapt, and grow in ways I hadn’t anticipated. This pattern has shifted my perspective towards seeing high-pressure situations not as threats but as opportunities to push my boundaries and accelerate my growth. It’s a mindset shift that encourages embracing challenges as catalysts for development.

Disagreements and Critiques: A possible critique of “The Deep End” is the risk of burnout or failure when taking on too much, too soon. The balance between challenging oneself and knowing one’s limits is delicate. While I agree with the core premise of the pattern, it’s crucial to approach such situations with a clear understanding of personal and professional support systems and a realistic assessment of the risks involved. It’s about finding the right challenges that push you without pushing you over the edge.

Conclusion: “The Deep End” pattern offers a powerful framework for thinking about professional growth and development. It challenges us to redefine our relationship with discomfort and uncertainty, viewing them as necessary elements of meaningful progress. As I look to the future, I’m more open to opportunities that may initially seem daunting, with the understanding that these experiences are invaluable for developing the skills, confidence, and resilience needed to succeed in an ever-changing professional landscape.

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

In this blog post, we will delve into the realm of copyright protection, licensing, and explore how to use content ethically on your blog.

Copyright Fundamentals

Copyright is the legal foundation asserting that creative works such as art, writing, images, and music belong to their creators. Anything you create and record in a lasting form is your intellectual property. Others cannot legally copy or profit from your work without your permission.

Types of Licensing: Traditional Copyright, Creative Commons, and Public Domain

1. Traditional Copyright: Strict protection; requires permission for use, adaptation, copying, or publishing.
2. Creative Commons: Allows usage under specific conditions set by the creator (e.g., attribution, non-commercial use, no derivative works).
3. Public Domain: Completely unrestricted use, no permission needed (applies to works published before 1923, creations of long-dead creators, or works intentionally placed in the public domain).

Using Public Domain and Creative Commons Content

Public Domain Content

No restrictions on usage, but identifying such content can be challenging. Useful sites include:

• Prelinger Archives
• U.S. Government Photos and Images

Creative Commons Content

Free to use but with conditions set by the creator. License types include attribution, non-commercial use, no derivative works, and share alike. Sites for finding such content include:

• Wikimedia Commons
• Flickr’s Creative Commons Search
• Creative Commons Search

Using Copyrighted Material

Fair Use Guidelines

Fair Use allows limited use of copyrighted material for purposes like commentary, criticism, reporting, and teaching. Guidelines include:

• Majority of content must be your own.
• Properly credit the copyright holder.
• Non-commercial use is generally safer.

Misusing Copyrighted Material

Even with good intentions, a copyright holder may disagree. Consequences may include blog shutdown or legal action. Remove contested content if requested.

Licensing Copyrighted Content

To use copyrighted material outside of Fair Use, obtain a license. Stock photo sites for licensed content include:

• iStockphoto
• Photos.com
• Fotolia

Sharing Copyrighted Videos

Embedding videos from YouTube or Vimeo is common, but beware of copyright violations. Ensure the video creator is credited. Illegally shared videos may lead to removal.

Protecting Your Intellectual Property

Your content is also protected by copyright. Safeguard it by:

• Using plagiarism search services (e.g., Copyscape).
• Setting up Google Alerts for excerpts of your posts.
• Adding watermarks to your images.

What to Do if Your Content Is Misused

Contact the blogger or site using your content, requesting removal or proper credit. If unsuccessful, consider filing a DMCA takedown request, following legal procedures outlined in the Digital Millennium Copyright Act. Remember, respecting copyright and licensing not only preserves the rights of content creators but also upholds the integrity of your blog. Happy and responsible blogging!

https://edu.gcfglobal.org/en/blogbasics/copyright-and-fair-use/1/#

From the blog CS@Worcester – Coding by asejdi and used with permission of the author. All other rights reserved by the author.

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.