For this week’s blog post, I decided to discuss the article “Object-oriented Testing in Software Testing” by Mitali Varatiya. I chose this article because it compliments the object oriented testing topic in the syllabus. This article discusses what object oriented testing is, how you can develop test cases with object oriented testing, how to implement object oriented testing, different techniques with implementing object oriented testing, and challenges associated with the implementation of object oriented testing.

The author first discusses how object oriented testing can be done at multiple levels of a program, for example the algorithmic, class, cluster, and system levels. “Object Oriented testing can be performed at different levels to detect the issues. At the algorithmic level, a single module of every class should be tested. As discussed earlier, testing of classes is the main concern of the Object Oriented program. Every class gets tested as an individual entity at the class level. Generally, programmers who are creating the classes are involved in testing. Test cases for Object-Oriented Testing in Software Testing can be constructed based on the requirement specifications, programming language, and models.” The author then goes on to discuss how, at the class level, testing focuses on the integration of individual classes and their interactions with other classes in the program. “Once class-level testing is done, Cluster level testing will be performed. Cluster-level testing is the integration of individual classes. The main purpose of doing integration testing is to verify the interconnection between classes and how well they perform interclass interactions.” The author also discusses some ways in which object oriented test cases can be developed.

The author states that conventional methods of developing test cases are sufficient for creating object oriented test cases, but there are some features that may be helpful with object oriented testing that might be looked over when using more typical techniques on their own. “The following points should be considered while creating test cases for object-oriented environments. Which class is going to be tested should be mentioned properly within the test cases. What is the purpose of using particular test cases? What external pre-condition needs to be conducted while performing the test case? All the states should be specified for testing.” The author then discusses some of the challenges with implementing object oriented testing.

Some challenges that are associated with implementing object oriented testing as described by the author are the impossibility of dynamic testing, the necessity of different types of testing to be implemented to properly test the program, and the difficulties associated with the implementation of testing for inheritance in object oriented programs.

Article: https://www.scaler.com/topics/software-testing/object-oriented-testing-in-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 a recent episode of the Python Test Podcast, titled “TDD: Don’t Be Afraid of Test-Driven Development”, developer Chris May shared his journey with Test-Driven Development (TDD).  If you’re a programmer interested in improving your code quality and development process, this blog post offers a summary of the discussion and explores why TDD is a powerful technique.

What is Test-Driven Development?

TDD turns the traditional coding process on its head. Instead of writing a large chunk of code and hoping it works, you start by defining the precise behavior you expect from a piece of code. These expectations are written as tests, and they will initially fail because the code itself doesn’t exist yet.

Key Concepts and Benefits of TDD

The core of TDD is the “Red-Green-Refactor” cycle:

1. Red: Write a failing test that reflects a desired feature or behavior.
2. Green: Write the simplest possible code to make the test pass.
3. Refactor: Improve the code’s design and readability while ensuring all tests continue to pass.

This approach offers several key benefits:

• Improved Code Design: By focusing on functionality first, TDD encourages you to create well-structured, modular code.
• Less Debugging: Catching errors as early as possible through tests greatly reduces time spent troubleshooting complex issues later on.
• Increased Confidence: A comprehensive test suite provides a safety net, allowing you to make code changes with less fear of breaking existing functionality.
• Living Documentation: Tests serve as a clear explanation of how your code is intended to work.

Overcoming Challenges with TDD

As Chris May discussed in the podcast, TDD requires a change in how you think about coding. Here are some common concerns and how to address them:

• “It feels too slow”: It’s true that initially, TDD might seem to slow you down. However, the time saved from reduced debugging and a more solid codebase easily makes up for it in the long run.
• “I don’t know how to write tests”: Learning to write effective tests is a skill in itself. Start simple and leverage online tutorials and resources specific to your programming language.

Resources for Learning TDD

• Books:
  • “Test-Driven Development by Example” by Kent Beck
  • “Growing Object-Oriented Software, Guided by Tests” by Steve Freeman and Nat Pryce
• Online Tutorials: Explore the numerous tutorials and guides tailored to different programming languages.

Conclusion

While it may have a learning curve, Test-Driven Development offers a structured and rewarding approach to software development. By embracing TDD, you can write cleaner, more maintainable, and ultimately more reliable code.

Podcast link: https://podcast.pythontest.com/episodes/76-tdd-don-t-be-afraid-of-test-driven-development-chris-may

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

A Path to Enhanced Development

Code reviews are an essential practice in software development, pivotal not only for error detection but also for fostering an environment of continuous learning and collaboration. When executed effectively, they can significantly enhance both individual skills and organizational efficiency.

The Foundation of Effective Code Reviews

An effective review scrutinizes how the proposed changes integrate with the existing codebase, focusing on clarity, correctness, and adherence to established coding practices. Reviewers should critically evaluate the necessity and implementation of the changes, suggesting more granular modifications if the changes are too expansive.

The Art of Communication

The tone in which feedback is delivered can dramatically influence team dynamics. Constructive feedback should be presented through open-ended questions and thoughtful suggestions rather than direct criticism. This approach encourages a collaborative atmosphere and reduces the likelihood of defensive responses. It is essential to recognize the efforts of developers and maintain an empathetic and supportive tone throughout the review process.

Decision Making in Reviews

The decision to approve changes, request modifications, or leave comments unresolved should be clearly communicated. Reviews should be flexible, allowing for follow-up changes when necessary, with reviewers making themselves available for quick re-assessments to accommodate urgent updates.

From Written Reviews to Direct Conversations

When extensive feedback from a review indicates potential misunderstandings, switching from written comments to direct conversations can be beneficial. This transition can help clarify issues more effectively and expedite the review process, especially in cases of complex or contentious changes.

Navigating Challenges in Remote Reviews

Remote and asynchronous reviews present unique challenges, particularly when reviewers are in different time zones. To mitigate these challenges, it’s advantageous to schedule discussions during overlapping working hours or to utilize video calls, enhancing clarity and collaboration.

Cultivating a Supportive Review Culture

Organizations should strive to create a culture that values thorough and empathetic code reviews, recognizing them as crucial to the development process. Continuous improvement in review practices should be encouraged, and engineers should feel empowered to both contribute to and learn from each review session.

By prioritizing effective communication, thoughtful feedback, and continuous improvement, organizations can make code reviews a cornerstone of development excellence, leading to higher quality software and more productive teams.

Integrating Newcomers through Code Reviews

For new team members, adapting to a new codebase and review process can be daunting. A supportive review culture is crucial in easing this transition. Experienced reviewers should use the initial code reviews to not only evaluate the technical aspects but also to mentor and guide newcomers. By explaining alternative approaches, pointing to coding guidelines, and maintaining a positive tone, reviewers can help new engineers integrate effectively while maintaining high standards. This practice ensures that new developers feel welcomed and supported as they navigate their initial contributions to the team.

Based on this blog link: https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

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

Although I wasn’t present for the class in which code reviewing was introduced, it seems like a pretty simple topic to understand. It consists of… well, reviewing code; the only thing is, it can’t be done alone. Code review’s core and effectiveness lies in cooperation with others, where two or more people are required to even attempt code review. Of course, you can literally “code review,” as in, you review your own code but this refers to something more. 

What does it mean to review when it comes to code? Well, everyone is human, for the most part, and humans are prone to mistakes; and in the case of developers, these end up as bugs, errors, and everything in between. Code review allows others to look through one’s code to find these mishaps that the original developers may have missed or overlooked. I am also human and have had many cases in which I get stuck and have to ask a friend to look through my code just for them to point out something so simple and easy to spot yet I managed to miss. 

Code reviews encompass not only the spotting of mistakes but also the improvement of overall code, so as to have a better, more-refined end product before merging and such. This improvement of overall code includes but is not limited to structure, cohesion, cleanliness, and readability. Clean code is something that I hadn’t heard of until somewhat recently, so that aspect of my code from the past and even now can be improved upon heavily and would be greatly appreciated. 

Code reviews are usually chances for the one being reviewed to correct their mistakes and improve their code but there is also an opportunity for the reviewer to learn. The reviewer may encounter new techniques, solutions, and perspectives through this process, ultimately benefiting both reviewer and reviewee. 

One of the major downsides to code review is that the length and content of them depends entirely on the length of the code; and code can get to some very large sizes. The time spent reviewing especially large code could potentially be put into the current project, workflow, or what have you. 

As someone who is not so confident in their coding skill and proficiency, I believe that code reviews are great opportunities to learn and improve, which will in turn improve my confidence in my skill. There is much to be gained with code review and the downsides seem to only apply to much larger projects; so as a student and novice developer, they will be great to implement to my learning.

https://medium.com/@priyanthinisivasubramaniyam/everything-to-know-about-code-review-as-a-beginner-2a360cdd89ca

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

Introduction

The blog, “A Short Guide to Open Source Licenses,”by David Skaife, helps us understand the often confusing world of open source licenses. Let’s break down the key points to make sense of why these licenses matter in the world of computer software.

Understanding Open Source Licenses

Open-source licenses are like rules for sharing computer code. They tell us how we can use, share, and change the source code. These rules help protect the original creators and make it easier for others to use the code without asking for permission each time.

Clearing up Myths: Public Repositories and Licensing

Skaife talks about a common misunderstanding of just putting code on a public platform, like GitHub, doesn’t automatically make it open source. Without a clear set of rules (license) with the code, it’s still protected by copyright, and others can’t freely use or change it. So, it’s crucial to attach a license if you want others to use your code.

Making Sense of Licenses

Skaife acknowledges that there are many licenses, but he suggests focusing on a few popular ones. He also mentions the Open Source Initiative (OSI), which approves licenses, making it easier for us to choose from reliable options.

License Types: Strict vs. Flexible

There are two main types of licenses – strict (copyleft) and flexible. Strict licenses say that if you change the code, your new version must also follow the same rules. Flexible licenses are more relaxed, letting people use, change, and share the code more freely.

Exploring Five Common Licenses

There are five common licenses we might choose from:

1. MIT License: Simple and flexible, allowing changes with few conditions.
2. Apache License 2.0: Similar to MIT but a bit more complicated, addressing specific issues like trademark rights.
3. GNU General Public License (GPL) v2.0 and v3.0: Strict licenses, ensuring all changes follow the same rules, with v3.0 adding more details.
4. GNU Lesser General Public License (LGPL) v2.1 and v3.0: Less strict than GPL, allowing some exceptions for linking.
5. Berkeley Software Distribution (BSD) 2-clause and 3-clause variants: Flexible licenses, similar to MIT, with the 3-clause version having extra rules about using contributors’ names.

conclusion

Skaife’s guide helps us navigate open source licenses, making it easier to understand the rules for sharing and using computer code. With this knowledge, anyone working with open source software can feel more confident contributing, using, or creating, fostering a collaborative and innovative community. For those wanting more information, Skaife suggests checking out resources like the Open Source Initiative’s licenses pages and GitHub’s “choosealicence.com.”

reference

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

APIs, or Application Programming Intеrfacеs, sеrvе as softwarе intеrmеdiariеs facilitating communication bеtwееn divеrsе applications or dеvicеs. Thеy arе vital for intеraction with wеb browsеrs, mobilе dеvicеs, and third-party softwarе. APIs opеratе through protocols, primarily ovеr thе intеrnеt using HTTP, and arе likеnеd to a mеdiator facilitating communication bеtwееn a usеr and a backеnd systеm.

REST APIs, a usеr-friеndly stylе of API architеcturе, usе HTTP mеthods likе GET, PUT, POST, and DELETE. REST API Managеmеnt involvеs four kеy componеnts: API Dеsign, API Gatеway, API Storе/Dеvеlopеr Portal, and API Analytics/Dashboard.

Thе principlеs of writing clеan codе еmphasizе using commеnts judiciously, brеaking down mеthods into focusеd units, incorporating unit tеsting, and еliminating codе duplication. Clеan codе еnhancеs rеadability, еfficiеncy, scalability, and rеducеs thе likеlihood of introducing bugs.

Documеntation is crucial for codе maintеnancе and collaboration, еncompassing low-lеvеl or inlinе documеntation, high-lеvеl documеntation, and walkthrough documеntation. Convеrsеly, anti-pattеrns likе Spaghеtti Codе, Goldеn Hammеr, and Boat Anchor hindеr codе maintainability and dеvеlopmеnt.

Dеv Containеrs, or dеvеlopmеnt containеrs, offеr a complеtе and isolatеd dеvеlopmеnt еnvironmеnt accеssеd through SSH in prеfеrrеd IDEs. Thеy addrеss sеtup configuration issuеs, standardizе projеct build instructions, еnsurе isolation of dеvеlopmеnt еnvironmеnts, еnablе consistеncy across tеams, and simplify onboarding and training procеssеs. Thеir adoption is bеnеficial for rapid dеvеlopmеnt, prototyping, and addrеssing challеngеs associatеd with divеrsе local еnvironmеnts.

This is just a quick summary of what I have been through in CS-343. It was a very impactful semester that taught me many new things. I believe what I enjoyed the most was working collaboratively in teams. I find myself always working better in a structured group and retaining information much better. Towards the end of the semester, when we started to work with APIs, specifically the backend/frontend, I noticed a big usage of JavaScript. The homeworks became a little more challenging because of this, and I am going to use my break to get a crash course in JS. I also am working on a personal project where I will soon be implementing a frontend GUI, so the timing works out great.

I also cannot wait for the capstone class next semester as the whole idea behind the class just sounds perfect. I am a very hands-on guy, so getting to finally work on an actual project for a semester with a team and implementing what we learned will be a learning experience. Also, a great way to practice for internships and job opportunities for the future.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

https://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

https://swimm.io/learn/code-documentation/code-documentation-benefits-challenges-and-tips-for-success

https://www.atlassian.com/agile/project-management/scrum-values#:~:text=Scrum%20is%20a%20set%20of,solving%20and%20reducing%20project%20timelines.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Earlier in the semester, we discussed licenses and copyright in regards to our code and documentation. I’ve wanted to write a post on licenses, but finding a post that did more than describe the definitions and uses of licenses was difficult. Luckily, I have found a blog that describes software license management, the best practices, and some drawbacks when managing licenses. From those sections, I want to highlight the parts that felt the most important. The blog is called, “Seven Best Practices for Managing Software Licenses” by Ibrahim Ogunbiyi, a data scientist and IT support specialist.

The post starts off with defining software license management as the process of controlling, tracking, auditing, and managing the use of software in an organization. They highlight the importance of using SLM in many ways, but the one that stood out to me was to ensure the software is secure and has no malicious code. If there is no liability in the rights listed by the license or the lack of one, I can imagine how it would be important to sift through each one to ensure the code is safe to use. Another one that felt important was keeping track of software due dates. Having your team or company rely on access to software only to have it pulled from you could be expensive and time wasting. If you fail to stop after your access is revoked, you could be held liable and sued.

The potential setbacks of SLM were the cost, complexity, and compliance risk. In an organization or large company dealing with a myriad of different license types and potentially using them in combination with each other, I can see how those issues could come up.

The best practices discussed in the post that I found most important were documentation and training. Any issues that arise when dealing with license issues would be incredibly hard to fix if you cannot find relevant information. Keep track of everything, within reason. I have worked in a company that had one person in our location who was fully trained to use the company’s software. She was berated with questions about how it worked without every employee getting a full understanding of the system. She was the linchpin. After she left, so many things fell through the cracks and I can only imagine how detrimental that could be when dealing with licenses. Making sure everyone is on the same page with a full understanding of how licenses work will save companies a lot of time and money.

After reading this post, I felt like this would be especially helpful for people starting their own company. Understanding the complexities and importance of software development can only help in the future. Although I do not feel like I will be making decisions on implementing a software management system anytime soon, I will still keep what I learned in mind when dealing with licenses.

The blog post: https://www.wrangle.io/post/seven-best-practices-for-managing-software-licenses

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

Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.

            The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.

The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language.  I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.  

The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.

The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.

Link to the blog: https://www.aswf.io/blog/inclusive-language/

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

What is a Dev Container?

A Dev Container, or development container, encapsulates a complete development environment accessible through Secure Shell (SSH) in your preferred Integrated Development Environment (IDE). It overcomes workflow impediments such as low performance and limited bandwidth by providing an isolated environment with standardized configuration stored in a .devcontainer.json file. This JSON file, structured with Comments (jsonc) metadata, allows customization for specific needs, such as adding tools or extensions.

Why Use it?

Addressing Setup Configuration Issues: Maintaining and managing local environments involves the use of various tools and configurations, leading to a cumbersome process. Standardizing this process with a unified approach can significantly save time and streamline setup configurations.

Standardizing Build Instructions of the Project: Documenting dependency upgrades and changes can be challenging. Utilizing code rather than extensive documentation simplifies the process, enabling anyone to ship without being hindered by the “it works on my machine” dilemma.

Ensuring Isolation of Development Environments: Developers often work on multiple projects simultaneously, each with its own complexities. Isolating environments prevents conflicts with other software on the host system, creating a clean, controlled space for development tasks.

Enabling Consistency Across Development Teams: Achieving portability across diverse teams is complicated by varying technologies and configurations. Implementing a standardized development environment ensures uniform configurations among team members, minimizing inconsistencies from individual machine differences.

Simplifying Onboarding and Training Processes: Quickly launching environments in isolation facilitates learning new languages or frameworks. This approach is particularly beneficial for onboarding and training processes, keeping machines clean and allowing for smooth presentations and workshops, where everyone can follow along without interruptions caused by missing tools or confusion mid-step.

Dev Containers in Real World Enviroment

1. Standardized Development Environments:
   • Dev Containers provide a standardized and reproducible development environment, ensuring that all team members work with the same configuration. This minimizes the “it works on my machine” issue and streamlines collaboration.
2. Setup Configuration Management:
   • Addressing setup configuration issues is simplified with Dev Containers. They help in managing dependencies, tools, and configurations uniformly, reducing the time and effort required for setting up development environments.
3. Version Control Integration:
   • Dev Container configurations are often stored in version control systems (e.g., Git), ensuring that the development environment is versioned along with the code. This enhances collaboration and makes it easier for team members to switch between branches or versions seamlessly.

Personal Experience

Dev Containers are something I have recently just learned about, and I feel like the need for them is understated. The overall idea behind such a tool is to create a simple and consistent environment for a team to work in. Anytime I work on a project, I stress the need for one as it eliminates many common problems teams face in the early stages of development. I also believe that when I start my professional journey, I will find these containers to be more standardized within the teams I work with.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

After reflecting on the previous blog that I had written about coding, I pondered about what would happen if I were to work with software, and I immediately wanted to consider something about a software’s own making. For this blog, I decided to focus on Software Framework, which many programmers and organizations make great use of in the workforce. I took great interest in an article written by Tiago Monteiro, fittingly titled “What is a Software Framework?” It starts by giving the reader a simple concept where a man uses an axe to cut trees and then cuts wood to use for his fireplace for his family. When the chainsaw was introduced into this analogy, it related really well to programming, where you either start with fresh new code or make use of an existing framework done by another user to build your program. Reading more into the article, I found that there were advantages and disadvantages to using a software framework. While a framework is how anyone would start to form their own software, nobody has much freedom to alter the framework, limiting the use of a software framework to the functionality it was designed for.

I chose this article for my blog, because I believe that this article might help me in understanding a bit more about Software Engineering. Although the author of this article is a high-end Computer Engineer, his article could still give me an idea of what I should visualize when I start to learn more about designing software. A software has to have a framework to maintain functionality so it does not become inept, just as a computer will stop working if one of its most important parts either burns out like a wildfire or starts to malfunction upon reaching the end of its half-life.

My biggest takeaway from this article is that there are lots of software frameworks with many functionalities that are made useful in different manners.  Just as we try to create the framework to integrate smart machines into our appliances and everyday tools, we try to do the same with creating framework in our software as well.  We give life to our software the same way we try to create new computers, by giving it a spark of new and innovative programs for the greatest user and technological experience.

Reference: https://www.freecodecamp.org/news/what-is-a-software-framework/

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