In the world of software development, ensuring code quality is paramount. It’s not just about writing code that works; it’s about ensuring that the code is robust, reliable, and maintainable. This is where various testing methodologies and tools come into play. In this blog post, we’ll explore three crucial aspects of code quality enhancement in JUnit: Smoke and Acceptance Testing, Exploratory Testing, and Static Analysis.

Smoke and Acceptance Testing: Smoke testing, also known as build verification testing, is a preliminary test that focuses on ensuring that the most critical functionalities of an application work. It aims to identify fundamental issues that might hinder further testing. Acceptance testing, on the other hand, evaluates whether the software meets the acceptance criteria and is ready for release.

JUnit, a popular testing framework for Java, offers robust support for both smoke and acceptance testing. Through annotations and assertion methods, developers can easily write tests that verify the functionality of their code. By running these tests regularly, developers can catch regressions early in the development cycle, thereby ensuring a smoother development process and a higher quality end product.

For further information on Smoke and Acceptance Testing, you can refer to the documentation here.

Exploratory Testing: Exploratory testing is a hands-on approach where testers explore the software application without predefined test cases. Instead, testers rely on their domain knowledge, intuition, and creativity to uncover bugs and issues. While automated tests are valuable, exploratory testing can uncover issues that automated tests might miss.

In JUnit, exploratory testing can be facilitated through the use of parameterized tests and dynamic test generation. These features allow testers to generate test cases dynamically based on various inputs, enabling thorough exploration of the codebase.

To learn more about Exploratory Testing, you can explore the documentation here.

Static Analysis: Static analysis involves analyzing the code without executing it, typically to find potential defects or code smells. In JUnit, static analysis can be performed using various plugins and integrations with static analysis tools like FindBugs, PMD, and Checkstyle. These tools analyze the codebase for issues such as potential bugs, code style violations, and performance bottlenecks, providing developers with valuable insights into improving code quality.

For detailed information on Static Analysis in JUnit, you can refer to the respective documentation of static analysis tools and plugins integrated with JUnit.

In conclusion, leveraging Smoke and Acceptance Testing, Exploratory Testing, and Static Analysis in JUnit can significantly enhance code quality, leading to more robust and reliable software applications. By incorporating these practices into the development workflow, teams can streamline the testing process and deliver higher quality code with confidence.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

After my week of spring break, I’m looking to get back to building constructive habits and reinforcing my software development fundamentals. I was inspired to return to this chapter of the “Apprenticeship Patterns” textbook because I recently learned about a computer science problem called the Circle-Ellipse problem.

This hypothetical problem is meant to highlight the limitations of the object-oriented programming paradigm, specifically when using subtype polymorphism in your class design. In the Circle-Ellipse problem, two classes are defined, Circle and Ellipse, with the Circle class inheriting from the Ellipse class. The Ellipse class includes two member methods, stretchX() and stretchY() which can modify, or mutate, two private member variables of Ellipse each representing an X and Y coordinate. The programming language understands all instances of the Circle class as also being instances of the Ellipse class with this inheritance relation. The problem arises when considering the requirements of a subclass. A subclass needs to implement all the member variables and methods of its parent. The Circle class needs to implement stretchX() and stretchY() as a subclass of Ellipse. Using either of these methods to change the dimensions of the Circle would consequently make that object no longer represent a mathematically correct circle.

As this problem was explained to me, the Liskov Substitution Principle was mentioned. I remember reading about this principle as one of the 5 SOLID software design patterns. The Liskov Substitution Principle essentially states that in a program using subtype polymorphism, an object ought to be able to be substituted by one of its subclasses without breaking the program. The Circle-Ellipse problem represents a violation of this principle because an Ellipse cannot be substituted for a Circle except in one very specific case.

I hadn’t considered the limitations of inheritance relationships in software design before learning about this problem. I decided that after the lecture where I learned about the Circle-Ellipse problem, and after seeing so many titles and authors name dropped in “Apprenticeship Patterns”, that I should start compiling a reading list and start more intentionally defining my daily schedule, including time for reading about software design and computer science. I started with a summary of the Circle-Ellipse problem, and then went through the appendix in “Apprenticeship Patterns” to choose a few books that the authors cited the most often.

The pattern introduces the possibilities of making your reading list public on the internet or using an existing list to source further reading material. The reader is also prompted to look ahead to the future and maintain the reading list to use for reflection on their learning journey.

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.

The pattern of “The Long Road” highlights a common dilemma faced by aspiring software developers in today’s fast-paced industry. It contrasts the culture of instant gratification and superficial success with the desire to pursue mastery and craftsmanship in software development.

What intrigues me about this pattern is the disconnect between the long-term goals of becoming a proficient software developer and the short-term pressures to prioritize immediate financial gain and career advancement. Especially early in their careers, developers find themselves torn between these conflicting expectations while navigating through the complexities of the industry and trying to establish themselves.

This pattern resonates with me personally because it highlights the internal struggle I have faced in my own journey as a software developer. While I have not had any significant offers in the field of work yet, I know that true fulfillment in this line of work comes from the pursuit of excellence, continuous learning, and honing one’s craft over time. With my focus on excellence in my personal craft, it will pay off for me in the future later down the road.

The notion that the lessons and wisdom of seasoned software developers often goes unheeded in an industry that is constantly chasing the next big thing I found thought-provoking. The lack of knowledge transfer between generations of developers leads to the repetition of past mistakes and the reinvention of the wheel.

This pattern has caused me to reconsider my approach to my intended profession and how I want to work. Rather than falling into the external pressures and expectations, I am more committed to stay true to my passion for software development and prioritizing personal growth and mastery over short-term gains.

While I understand the advice to prioritize financial stability and career advancement, I do not completely agree with the notion that slow and steady skill-building is somehow less valuable or important. I believe that the pursuit of mastery is what ultimately sets exceptional developers apart and leads to long-term success and fulfillment in this field. I remain steadfast in my commitment to honing my skills, embracing lifelong learning, and striving for excellence in my craft, regardless of the trends or societal expectations.

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

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.

When you go to write code, maybe you already know what you want the code to do, knowing what it should give you as outputs and answers, but you might not know how to go about writing the code itself. In test driven development, you start with writing the tests first, and then trying to pass those tests, slowly as you go. It sounds like a strange approach to it but it is not as bad as it sounds.

In this blog post, Arek Torczuk talks about test driven development, and how it is the best thing that can happen to software development. First, they start off by describing test driven development, where they say it is, simply, a failing phase, a passing phase, and then a refactoring phase. In the failing phase, we create a test that will fail. In the passing phase, we create or write code, minimal code, that will pass the test. In the refactoring phase, we clean up the tests. Typically with coding, you would write the code, and then write tests. However, Torczuk presents some problems with this way of code development, like when to stop writing tests, or when you are sure implementation is finished. With test driven development, they say there are benefits, such as when writing tests, it makes you ask yourself, what do you want the code to do. They say that you should know the answers to these tests before the code is written. They then go on to provide situations where code may be impossible to test, and how test driven development can be used to help that, like using mocking. They provide code examples with these too, to further help visualize solutions. They provide some additional sources at the end of the article in the event you would like to learn more about test driven development. 

This is a strange way to write code, and for those used to writing code before everything else, this can be a difficult adjustment. Personally, I found it fairly difficult to start, but afterwards I was able to write the tests, and then write the code to pass those tests, and then keep doing that. The tests do provide a build up of the code, instead of doing everything all at once, which was what Torczuk was trying to get at with his blog post. It allows the tests to provide the framework of the code and lay it out. 

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Summary

In the world of software development, the mantra of “Practice, Practice, Practice” resonates deeply with aspiring craftsmen. This pattern from the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye emphasizes the critical role of deliberate practice in mastering any skill, especially in the realm of programming.

My Reaction

The essence of this pattern is simple yet profound: improvement comes through consistent and focused practice. As I delved into this pattern, I couldn’t help but reflect on my own journey as a budding software developer. Often, I find myself oscillating between bouts of intense coding sessions and periods of procrastination. This pattern serves as a wake-up call, reminding me that true growth stems from disciplined and purposeful practice.

What struck me as particularly insightful about this pattern is its emphasis on deliberate practice. It’s not just about clocking in hours mindlessly; rather, it’s about setting specific goals, pushing oneself out of comfort zones, and seeking feedback to refine one’s skills. This approach resonates with the concept of “deep work” championed by Cal Newport, where undistracted focus on challenging tasks leads to substantial progress.

This pattern challenged my perception of talent and innate ability. The authors stress that talent is overrated and that mastery is achievable through dedicated practice. This perspective is empowering as it shifts the focus from fixed traits to actionable steps that anyone can take to improve.

However, I do have a slight disagreement with the notion that “talent doesn’t matter.” While I agree that hard work and practice are paramount, acknowledging individual differences in aptitude can also be valuable. Some may grasp concepts more quickly or possess a natural affinity for certain aspects of programming. Nonetheless, the core message of this pattern remains invaluable: consistent practice is the cornerstone of excellence.

As I reflect on how this pattern has influenced my approach to software development, I am inspired to adopt a more structured practice regimen. Setting aside dedicated time each day for deliberate practice, tackling challenging problems, seeking constructive feedback, and tracking progress are strategies I plan to implement rigorously.

The “Practice, Practice, Practice” pattern serves as a powerful reminder of the transformative impact of focused practice. It has reshaped my mindset, emphasizing the journey of improvement over notions of inherent talent. Through disciplined practice, I aim to embark on a path of continuous growth and mastery in software craftsmanship.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Recently in my Cs-443 class, Software Quality Assurance and Testing, we have been talking about unit testing using stubs. Honestly, I didn’t understand what stubs were during the classes themselves, but a blog called Why Stubs in Unit Testing Improve Integration Testing helped me understand what a stub is, as well as where and when it is used. In this blog written by Miroslaw Zielinski, he states ” Unit testing is more about isolating the function, method, or procedure, otherwise referred to as a unit. This isolation is done by stubbing out dependencies and forcing specific paths of execution. Stubs take the place of the code in the unit that is dependent on code outside the unit.” Stubs allow the person testing the code to test specific paths of execution within the code, allowing them to view different things such as if different parts of the code work and are reliable. I think that Zielinski gives a great example of why these stubs are used in his article. He states, “Once the stub is added, it will be consistently applied to the tested code. A user working on the “allocation failure” test case will have an easy way to install a special callback function into the stub, which will simulate the desired effect: allocation failure or do nothing since by default the stub returns a null pointer, which is expected for the test case.” This helped me understand why stubs are used, and the rest of the article helped me understand when they are used.

After reading more of the article, Zielinski began to explain why stubs are used. Although his explanation confused me a bit, I believe I got the jist of what he was trying to say. I believe that they are being used when you are trying to test lower-level modules while the upper-level modules have not been developed yet. Therefore you can use a stub, which acts like an upper-level module, in order to see how it will be treated. Zielinski also gives examples of when stubs aren’t good to use and what the limitations are “In instances where there’s not an original definition available for a stubbed function, what happens? How does the stub behave without a callback that defines the alternative behavior? The beauty of C/C++test is that it automatically detects this kind of situation. The stub will reconfigure itself during the test harness build time. It won’t call the original definition when no callback is installed and will return a safe default value.” I’m not really sure what he means by this, but I hope to learn more in the future.

Link: https://www.parasoft.com/blog/using-stubs-in-integration-level-testing/#:~:text=Unit%20testing%20is%20more%20about,on%20code%20outside%20the%20unit.

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.