URL: https://stackoverflow.blog/2022/01/03/favor-real-dependencies-for-unit-testing/

Mark Seeman brings us an interesting idea about which dependencies should be used during testing. In his article Favor real dependencies for unit testing, he explains that not every dependency necessarily helps you develop your tests. His main point concerns the use of dependencies that generate some kind of fake implementation of your methods in order to allow you to test them. One great example of this is Mockito, a widely used Java library where you can ask the tool to mock an entire class implementation. Although that sounds completely reasonable at first glance, what could be one issue that Mark is possibly missing in his argument? I would say that he is missing the reason why developers often rely on mocks and stubs in real-world development scenarios.

The main reason someone may choose to use mocks and stubs is more related to collaborative group work rather than projects handled by a single developer. In group settings, such as when working on a complex system like a hotel booking website, developers are usually assigned to different components or features of the system. For example, imagine a situation where you are working as a developer on such a project and are responsible for the Bookings class, while your teammate is assigned to the Suites class. Both of you have been making progress on your respective parts, and now you want to start writing tests to ensure everything functions as expected.

However, if any of your methods rely on a function that your teammate has not yet implemented, you could run into difficulties. Without the other function available, you might not be able to fully test your own code, even though your part is technically complete. This could lead to a development bottleneck, preventing you from moving forward until the rest of the system is ready.

To solve such a problem, one practical solution is to use libraries like Mockito. These tools allow you to create a mock version of your teammate’s class or method, enabling you to continue writing and running tests without delay. As explained earlier, Mockito generates fake implementations that simulate the behavior of the real components. This makes it possible to isolate and verify your own code independently.

Mark’s point is valid in scenarios where a developer is solely responsible for both the implementation and testing of all related methods. In such cases, using real dependencies like database fakes or stubs may be more effective. However, in collaborative environments, mocking libraries are essential tools that support parallel development.

This article surprised me with its perspective and application. As I’ve learned in class, the use of mocks allows developers to test features that haven’t been implemented yet adding a useful layer of abstraction. I believe that such libraries are not meant to stay in the codebase permanently but rather serve as temporary scaffolding—tools meant to be discarded once the full system is in place.

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://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.