URL: https://www.testscenario.com/black-box-testing/

Black box testing is a great tool for improving functionality, identifying issues within the user interface, and, in many cases, it does not require any programming knowledge. It also plays a key role in validating system acceptance, pre-launch stability, security, and third-party integrations. These aspects make black box testing a highly valuable method not only for developers but also for testers and stakeholders.

It offers great advantages when it comes to presenting results to the customer in order to gain approval. Because it follows a more user-oriented approach, black box testing produces results that are of interest to clients and stakeholders. This approach is referred to as Functional Testing. Additionally, black box testing can be used to assess user-friendliness, usability, and reliability—all of which help ensure that the software runs smoothly and provides meaningful feedback. This type of testing is known as Non-Functional Testing.

Regression Testing, another form of black box testing, ensures that new features or updates do not break any existing functionalities. This is especially important when a software release includes significant or breaking changes. User Acceptance Testing (UAT) typically takes place in the final phase of the testing cycle, where end users verify whether the software meets the necessary business requirements before its official release. Lastly, Security Testing serves as a method of vulnerability assessment, aiming to expose a system’s weaknesses and protect it against potential cyber threats.

The main reason I chose this article is because black box testing, to me, always seemed a little meaningless. Why would anyone test something without reading the code? But after reading the article, I realized that developers actually perform this kind of testing quite often—especially in web development. We constantly test various inputs without necessarily diving into the source code. The article also helped me understand that black box testing is an excellent tool for non-developers, allowing them to effectively test and better understand the product without having to read hundreds of lines of code.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URL: TestoMat Mocha and Chai Web Application Testing
The chosen article walks us through the implementation and inner workings of two JavaScript testing tools. Mocha and Chai are two different testing tools that, when combined, form a powerful addition to any software development project. Mocha serves as a test runner, being responsible for executing the test suites. While Mocha can function independently and does not necessarily require any additional tools, combining it with Chai, an assertion library, allows for the validation of expected outcomes in test cases.

The blog post also provides us with several reasons why the utilization of both tools can help improve your software development speed and quality. Among the listed benefits are:

Mocha:

• Flexible and customizable testing.
• Simplifies the testing of asynchronous code.
• The ability to apply before, beforeEach, after, and afterEach.
• Runs tests in both browser and Node.js environments.

Chai:

• Provides clear and expressive assertions that improve the readability of your test scripts.
• Allows you to write descriptive tests using natural language constructions.
• Enables the creation of custom assertions tailored to your specific testing requirements.
• Supports assertions on complex data structures such as arrays, objects, etc.

At the end of the article, it presents an opportunity to implement Mocha with some real-world examples, which is great and especially helpful for anyone unfamiliar with the framework.

The reason I chose this article relates mainly to another class. I will be taking on the task of developing test suites for the Thea’s Pantry app. I also found it interesting because it explains why you would use both Mocha and Chai instead of using other tools or Mocha alone.

The content is helpful and does not seem to include any bias by presenting Mocha and Chai as the only testing environment for JavaScript. Instead, it highlights their pros and invites the reader to determine whether these tools will suit their specific use case. One thing that caught my attention about using Mocha is its ability to generate documentation through testing. This is great, as it will help me better understand how documentation related to testing is created and how useful it can be.

Mocha and Chai’s use of natural, human-like language makes testing much easier. The use of natural or human-like language in programming often makes me skeptical of such tools, libraries, or frameworks. Sometimes, this characteristic is marketed as a way to draw people in, as if it will help them code more effectively. Although Mocha and Chai are distinct tools, their implementation of this characteristic leans more toward improving readability for the programmer rather than for just anyone. What I mean by this is that they avoid technical or overly formal wording in favor of keywords that resemble everyday human language.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URL: https://semaphoreci.com/blog/test-driven-development
The blog in question was written by Ferdinando Santacroce on Sephamore. The title is Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software. He walks his readers through many topics related to Test-Driven Development. These topics include TDD as a design practice, TDD as a well-established engineering practice, and many others.

Test-Driven Development caught my attention because it implies that the inverse of traditional testing should be done. Instead of writing tests for existing code, you should rather write tests for code that has yet to be written. This is confusing in some ways and also misleading when considering only the phrase “Test-Driven Development.” However, as we all know, every concept means more than just the words it comprises. And TDD (or Test-Driven Development) follows the same rule—it is much more than simply writing tests first.

I would personally call it a way of thinking or a different point of view on how tests and code are written. TDD resembles Agile and Scrum’s approach to software development. It shifts the developer’s focus from simply producing and creating large amounts of code—where everything eventually becomes one big entity—to a much more structured and manageable process. As Agile methodology suggests, it is better to build, review, test, and repeat. This method, combined with Scrum, takes this perspective further. Small chunks of functionality are built in shorter time frames, allowing for continuous review and feedback.

TDD applies the same principle with one key difference: test first—or at least, write your tests first. By writing down what should be tested and what a program should return or produce, you now have a clear goal. This method shifts the traditional way of thinking and provides a clear path to the main objective. This objective is then broken down into many smaller pieces that are easier to understand. Another benefit of TDD is the constant feedback, often called a “pleasing side effect.” Continuously receiving feedback on your code gives you a steady sense of accomplishment.

The outcomes of introducing Test-Driven Development into one’s development process can bring many benefits. However, beneficial outcomes are not guaranteed for every single person who applies this methodology. That said, I would argue that certain developers may benefit more than others. Developers who often feel lost, confused, or disoriented may benefit greatly from Test-Driven Development. This approach provides them with a clear understanding of the code’s structure in a more modular and organized way. By separating the code’s functions into different sections, building blocks, or containers, TDD creates a more structured and efficient development environment.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URL: https://getdx.com/blog/software-collaboration/

During this past semester, I learned more about what collaboration is and why it is so important. Collaboration is something that I personally find essential and key in software development. However, this semester, I learned the hard way how problematic the lack of collaboration from someone can be and how harmful it can be to a team. It doesn’t just divert attention from the focus, but it also disrupts the workflow and creates unnecessary stress. I don’t say this because I am the most collaborative person—believe me, I’m not. At times, I can be a difficult person to collaborate with. But through experience, I learned an important lesson: when team members don’t collaborate effectively, progress is slowed, creativity is hindered, and learning opportunities are missed.

You might ask me, “How would you bring together four or five different people from diverse origins, cultures, and sometimes even languages, and make them work seamlessly as a team?” Well, I don’t expect perfect communication or total synchronization—such perfection is simply unattainable. However, that doesn’t mean that everyone shouldn’t do their best to contribute. Does this mean the solution is cherry-picking people with similar backgrounds, races, and beliefs to simplify communication? The answer is still no. The strength of a team lies not in how similar its members are but in what they can contribute and their shared desire to grow and succeed.

Diversity within a team is also essential for solving complex problems. Individuals with different experiences and perspectives can offer unique insights and approaches that others might never consider. When people bring their varied backgrounds and creativity to the table, the possibilities for innovation and success increase significantly.

Ultimately, what matters most is the effort and willingness of each team member to collaborate and complete the work. Agile methodologies and Scrum are two approaches that I have found particularly effective in fostering a culture of communication and collaboration. Frequent check-ins, meetings, and milestone-based planning make it easier to stay aligned and on track as a team.

One blog post I came across this semester made me reflect on the importance of addressing issues directly. Ignoring problems, whether personal or within a team, doesn’t make them go away; it only exacerbates them. This realization pushed me to focus on self-improvement by being more open to new and different ideas. Even if an idea isn’t the most ideal solution, it can still lead to success.

Finally, open-source software is something I was unfamiliar with before. Now, I’m eager to contribute to such projects, especially those aimed at making a positive impact on the world.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

URLs:
Article on SOLID: https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/
Video mentioned: https://www.youtube.com/watch?v=j-6N3bLgYyQ

One video has always caught my attention because it clearly illustrates why SOLID principles are so important. I will reference two sources in this post for better understanding, in case you want to explore the topic further. However, I kindly ask you to watch the video linked at the beginning for my comments to make sense.

I chose an article to complement the video because it offers a more approachable explanation of SOLID principles and, as stated, explains them in plain English. The video features a dad following instructions from his kids to make a peanut butter and jelly sandwich. The issue here is that such a task may have become so automatic for us that we no longer think about every single detail involved.

How is that related to programming and SOLID principles? Well, it’s quite similar. At its core, code consists of lines and lines of instructions written for a machine to execute. To achieve the intended goal, these instructions must be precise and correct; otherwise, we can encounter numerous issues. As the video demonstrates, the lack of precision in the kids’ instructions led to some funny outcomes: first, the dad stacked two slices of bread on top of each other without doing anything else. In another instance, he ended up with a piece of bread with a “bit” of peanut butter on it, a whole bottle of jelly, and another slice of bread on top.

Did I just make a typo by saying a bottle of jelly was between two slices of bread? No, that did happen. This highlights what occurs when you assign certain instructions—or, in programming, functions (Single Responsibility Principle)—more than one purpose or intent. While a peanut butter and jelly sandwich recipe might not fully embody all five SOLID principles, the Single Responsibility Principle (S in SOLID) alone is enough to demonstrate the importance of clear and focused design in coding.

The lack of clarity and precision in the sandwich instructions led to various unwanted results. Although the instructions made sense to the kids, they didn’t work well for anyone else. Similarly, when writing code—whether for homework, work, or even personal projects—these principles should never be overlooked. I believe following such practices is part of a developer’s ethical responsibility.

At the end of the day, even if I’m the one reviewing my code a year later, I might struggle to understand it without proper adherence to these principles. You might wonder, “How is it possible not to understand what you wrote yourself?” Well, that’s exactly what happened to me yesterday while refactoring some old code. I encountered several parts that I couldn’t make sense of, so I had to revise and apply these principles to make them comprehensible.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.