Unit testing is a fundamental practice in software development, ensuring that individual units of code work as expected. However, the real challenge often lies in writing code that is easy to test. Poorly designed, untestable code can complicate unit testing and introduce expensive complexity. In this blog post, we’ll explore the importance of writing testable code, the common pitfalls that make code hard to test, and the benefits of adopting testable coding practices.

The Significance of Unit Testing

Unit testing involves verifying the behavior of a small portion of an application independently from other parts. A typical unit test follows the Arrange-Act-Assert (AAA) pattern: initializing the system under test, applying a stimulus, and observing the resulting behavior. The goal is to ensure that the code behaves as expected and meets the specified requirements.

However, the ease of writing unit tests is significantly influenced by the design of the code. Code that is tightly coupled, non-deterministic, or dependent on mutable global state is inherently difficult to test. Writing testable code is not only about making testing less troublesome but also about creating robust and maintainable software.

Common Pitfalls in Writing Testable Code

Several factors can make code challenging to test, including:

1. Tight Coupling: Code that is tightly coupled to specific implementations or data sources is difficult to isolate for testing. Decoupling concerns and introducing clear seams between components can enhance testability.
2. Non-Deterministic Behavior: Code that depends on mutable global state or external factors (e.g., current system time) can produce different results in different environments, complicating testing. Making code deterministic by injecting dependencies can address this issue.
3. Side Effects: Methods that produce side effects (e.g., interacting with hardware or external systems) are hard to test in isolation. Employing techniques like Dependency Injection or using higher-order functions can help in decoupling and testing such code.

Benefits of Testable Code

Adopting testable coding practices offers several benefits:

1. Improved Code Quality: Testable code is typically well-structured, modular, and easier to understand. This leads to higher code quality and reduces the likelihood of bugs.
2. Easier Maintenance: Code that is easy to test is also easier to maintain. Changes can be made with confidence, knowing that unit tests will catch any regressions.
3. Faster Development: With a robust suite of unit tests, developers can iterate quickly and confidently, reducing the time spent on manual testing and debugging.
4. Enhanced Collaboration: Clear and testable code promotes better collaboration among team members, as the intent and behavior of the code are easier to comprehend.

Conclusion

Writing testable code is a crucial aspect of software development that extends beyond the realm of testing. It encompasses good design principles, decoupling, and the elimination of non-deterministic behavior and side effects. By focusing on writing testable code, developers can create software that is not only easier to test but also more robust, maintainable, and reliable. Embracing these practices ultimately leads to higher quality software and more efficient development processes.

All of this comes from the link below:

https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

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

The blog post I’ve chosen talks about the different mind sets that you should use when tackling different situations. When writing tests, it helps to write tests with different goals so that you don’t forget to test every aspect of some section of code. The blog author talks about how trying to do the tests out of order or without any order in mind you can forget things and cause it to take more time in the long run. The author categorizes these as “hats” to wear during each progressive stage. There is the ambitious hat which is for when you are testing the code in the way the customer will be using the code. There is then an uncomfortable hat which is for when your tests are failing, and you need to fix what you can in your testing. The confident hat is the one you can wear while you are refactoring your code and running just to confirm everything passes. The author also makes specific mention to not try and wear multiple hats at once.
From my experience in the classes I’ve taken so far, I’ve done some built in testing in files for whole programs that I myself have written, and so I know exactly what the code should do, what I need to have pass in order to meet the homework criteria. In these cases, because I am both the author of the code and the author of the test cases, I am able to make edits in both parts with the knowledge of exactly what the test cases should be. This has helped in my current class so far but as we move forward, we will be approaching testing like it is done in the workplace and when the people testing the code are a separate group that has not touched the program code. I’ve definitely seen myself as the coder that the author describes who frantically moves around the code and tests trying whatever I can to get everything to work instead of approaching it with any methodology. I want to become both better and more efficient at testing code as it will help me write code also and further my understanding of what makes a complete program. Testing is a big part of working in the computer science field and I know that quality assurance is very important, so I look forward to both learning more about this within the course and doing more blogs about the industry.

Chris James – The TDD Thinking Hats

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.

Design patterns are essential concepts in software engineering, providing time-tested solutions to common problems. As an apprentice in computer science, understanding design patterns can significantly boost your coding efficiency and software design skills. During my learning journey, I found an insightful article, Java Design Patterns from GeeksforGeeks, that provided me with a solid foundation on design patterns. Here’s a summary of the article and my reflections on how it has shaped my learning experience.

Summary of the Selected Article

The GeeksforGeeks article Java Design Patterns covers the key design patterns used in Java programming. It introduces three main types of design patterns—Creational, Structural, and Behavioral. Each category is explored with practical examples and explanations that break down the complexities of design patterns into digestible information. The article also touches on popular patterns like Singleton, Factory, Decorator, and Observer, providing clear definitions and illustrating their use cases in real-world Java applications. It serves as an excellent resource for beginners to grasp how design patterns can improve code readability, reusability, and maintainability.

Reason for Choosing this Resource

I chose this article because GeeksforGeeks is known for delivering educational content tailored to both novices and experienced developers. I needed a source that could present design patterns clearly and practically, specifically for Java programming, which I am currently studying. The website’s step-by-step approach to explaining concepts, accompanied by code snippets, resonated with my learning style. As a beginner, I was looking for a resource that could demystify design patterns without overwhelming me with technical jargon, and this article did exactly that.

Personal Reflection and Key Takeaways

The material was enlightening, especially in how it framed design patterns as reusable solutions to software design issues. Before reading the article, my understanding of patterns like Singleton or Factory was limited to theoretical concepts, but the examples provided helped me visualize their practical applications. One major lesson I took from this article is the importance of the Singleton pattern, which ensures that a class has only one instance and provides a global point of access to that instance. This concept is essential in areas like database connections, where having multiple instances could lead to conflicts.

Additionally, learning about the Factory pattern—a creational pattern that allows for the creation of objects without specifying the exact class—opened my eyes to how flexibility and scalability are achievable in code. This pattern is especially helpful when dealing with large projects where new object types might frequently need to be added.

The article not only strengthened my grasp of object-oriented principles but also inspired me to think more critically about how I structure my code. It shifted my perspective from merely getting the code to work, to considering how to design it efficiently for future use and maintenance. I now see design patterns as a roadmap to writing better, more scalable code.

Future Application of Design Patterns

Moving forward, I plan to incorporate these design patterns into my coding work practices, particularly in my Java projects. The Singleton pattern will be useful in managing system-wide resources, while the Factory pattern will aid in developing modular code that can easily evolve. Understanding these patterns equips me to write code that is not only functional but also adaptable, which is crucial as I delve into larger, more complex projects.

In conclusion, design patterns are invaluable tools for every software developer. Thanks to resources like the GeeksforGeeks article, I now have a clearer understanding of how to implement these patterns in Java, and I look forward to applying them in my future projects.

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

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

This week, I am going to provide some insights/opinions regarding the practicality of some clean code principles, along with an example of when over-optimization for the sake of readability might actually be counterproductive. The resource I will be referencing this week can be found here. This article documents many of the same clean-code principles we discussed in class, plus or minus a few. For each principle, it provides an explanation as well as a coded example to demonstrate the principle and/or the difference between good and bad code according to the principle. I chose this article because I felt it was comprehensive enough to cover the key points for clean coding, and because I tend to use many of the principles outlined in the article in my own code.

I am currently involved in a project where the Single Responsibility Principle (SRP) might actually be counterproductive to my primary objective. In general, I tend to agree with this principle, and I understand its benefits well. It makes code far easier to read and follow, and, as we discussed in class, modern compilers can optimize functions to where there is almost no difference in execution time by offloading logic into its own function.

My program runs an ultra-fast search on a set of numbers (speaking very loosely), and needs to update numbers around 250 times per second. Thus, my time to find what I am searching for and act on it is ~4ms before all the data is useless (think: cracking Enigma in The Imitation Game). Now, factor in that I need the majority of the ~4ms to actually execute based on my search result, and one arrives at the conclusion that the search needs to take <1ms (or as little time as possible). Now to my point: sometimes, to accomplish this, I found that I had to violate the SRP. This means that I call search(), and search() immediately calls execute() if it finds what it’s looking for, eliminating the time it would have taken to return the value to main() and then pass the value back to execute(). This is obviously a miniscule difference, but in my testing and gathering data, I found that when multiplied out to larger and larger numbers, this little hack shaved off a noticeable amount of time.
This might all be more related to Command-Query Separation or the “No Side Effects Principle” than it is to the SRP, but my points still stand. What I am getting at in the big picture is that these principles, while applicable and preferable a massive portion of the time, are not always the right way to go. Sometimes, you have to sacrifice one or more in pursuit of your primary objective. All this said, my largest takeaway going forward is that I should remember and implement clean code principles whenever/wherever possible, but I will always try to remember that they are not law, and sometimes variance is necessary.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This week, I am going to be chatting about the benefits of Humanitarian Free and Open-Source Software (HFOSS). Prior to class this week, I was familiar with open-source software, as I have previously integrated some open-source projects into personal projects, but I had never heard of HFOSS specifically, and had not given thought to the potential benefits of popularizing HFOSS development in an educational environment. Instead of referencing a blog this week, I am going to look at an actual HFOSS project that can be found here.

Crisis Cleanup is a platform designed to connect volunteers with individuals affected by disasters, particularly during and after events like hurricanes. This project is a perfect example of HFOSS, demonstrating how collaborative, community-driven software can make a meaningful and real impact.

One of the coolest parts of this HFOSS project is its emphasis on community engagement. Crisis Cleanup operates on the principle that local volunteers can provide the most relevant and timely assistance to those in need. By facilitating connections between volunteers and those affected, the platform enables random people to help in ways they probably otherwise couldn’t. Combine this with the fact that anybody can contribute, and now there is a unique opportunity to create a learning environment for students. Contributors can gain practical experience in software development, project management, and user interface design while working on real-world challenges. Students can also witness the immediate impact of their contributions, reinforcing the idea that their work can lead to tangible change. As we discussed in class, this seems to raise interest/appeal in computer science in groups that are otherwise generally less interested in it, which is an awesome way to get more people involved in the field.

Crisis Cleanup also highlights the importance of adaptability in software development. During a disaster, the needs of affected individuals can change rapidly. HFOSS allows for quick iterations and updates based on feedback from users and volunteers on the ground. This agile approach to software development ensures that the platform remains relevant and effective, which is crucial for a disaster relief program in particular. I think another really cool thing about this HFOSS project (and HFOSS in general) is that the Agile methodology is generally used. It makes sense; Agile is not exclusive to professional software development teams, but to see it used or even suggested for an open-source project is not what I would have guessed at first.

Personally, I have always had an interest in Computer Science, regardless of my awareness (or lack thereof) of HFOSS. I have not yet contributed to any projects of that nature. Moving forward, maybe I will find one to contribute to on my own, now that I know how much they can help people. Overall, I think they are an excellent way to learn/enter the field of Computer Science, and I would love to see more educational environments centered around HFOSS development and projects like the Crisis Cleanup project.

From the blog CS@Worcester – Mr. Lancer 987&#039;s Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

The part of the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye that I find myself flipping back and forth through the most is the fifth chapter, titled Perpetual Learning. I’m planning to depend on my skills in software craftsmanship to establish a stable career and earn enough money to finance my other pursuits in life, and consequently I need to think seriously about nurturing my foundational skills and refining my learning process.

I’m taking a course this semester that has me relearning C++, a language that I haven’t used in several years. I had been programming almost entirely in Java since beginning Worcester State University’s Computer Science program, and the material of this course is requiring me to jump right back into the deep end of C++. I find myself unsure whether my approaches to certain challenges are correct or not, as well as feeling more concerned with whether my code will compile instead of whether I am learning the tools of the C++ language effectively.

When I want to truly absorb some kind of knowledge, I’ve realized that I learn something best when I receive positive feedback when I demonstrate my skills properly and correctly. When I wanted to learn how to play the guitar when I was younger, the first thing I tried to learn was the start of “Breaking The Law” by Judas Priest. The positive feedback I got from learning that part was hearing sounds from the guitar that I was playing that sounded a lot like actual music! After that, I couldn’t stop myself from learning how to be a better guitar player because of how much I wanted to keep myself in that positive feedback loop. I kept learning, I sounded better, and the feedback loop has been growing more rewarding as time goes on. I’m confident that lots of other people can relate to this experience, even if the thing that they were trying to learn wasn’t music or playing an instrument. Being able to gauge your own progress through positive feedback benefits the learning process dramatically.

This pattern is concerned with creating that same kind of positive feedback loop within the context of software craftsmanship. Seeing the quality of your output increase in proportion to your effort in learning can be the fuel that keeps a programmer engaged in refining their craft. The pattern is introduced with a quote from Jerry Weinberg’s “Project Retrospectives”:

“We in the software industry are working with a more or less invisible product, yet this very invisibility only heightens our need for feedback.”

It feels difficult for me to decide “where I am” as a programmer without comparing myself to the people around me. That approach takes my focus away from my own growth however, and I want to avoid it. So instead, the solutions proposed by this development pattern include researching test-driven development and using interactive interpreters that can let the programmer catch errors and see outputs as they write code. The programmer also has the option to intentionally reach out and seek feedback on their coding process from peers and mentors, or by participating in pair programming. A given example of applying this pattern in the real world is asking the interviewer for a position that you were not accepted for why the company didn’t want to bring you on board. This is a more positive framing of what could be a rather upsetting situation, and an outside perspective can also give you insight into aspects of your work and yourself you hadn’t paid attention to.

The key to collecting all this data is to construct useful and actionable feedback for yourself. The pattern defines “useful feedback” as feedback that you can do something in response to that informs you whether to do more or less of a certain behavior. The textbook challenges the reader to put this pattern into action by identifying a metric in their working environment that they have the capacity to change and measure. Then, use the measurements of that metric to try and understand how your actions have changed your “working environment”.

Reflecting on this pattern has made me realize that I have rarely, if ever, sought out external feedback for projects that I’ve worked on outside of school. I’ll write code, compile it, and push it to my Github, but I’ve never made the effort to construct testing suites or seek external criticism from other programmers. These habits have enabled a feeling of doubt to sprout within me about whether my code could be adapted to perform a useful task, or whether I’m actually making any progress in my learning. I’ve started thinking about the advice proposed by this development pattern, and I’m going to take the time to read “Test-Driven Development: By Example” by Kent Beck, the reading material sourced in this pattern. I’m also going to research the features of Visual Studio, my preferred text editor, to see if there are any extensions that allow for the features offered by interactive interpreters.

I’m not sure that I understand the pattern’s advice about “gathering metrics to understand the effects of your changes to your working environment”, but the practical advice of using software tools to provide feedback as you work as well as inviting constructive criticism from others makes perfect sense to me. The pattern also urges the learner to put themselves in situations conducive to building these feedback loops. I think that some of the strongest fuel for those feedback loops are the relationships we create with others along our learning journey, and in the online realm of software development, I don’t think it would be hard to find a community of developers eager to forge and fully energize those feedback loops.

From the blog CS@Worcester – Michael&#039;s Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Summary:

The pattern “Nurture Your Passion” addresses the struggle faced by software developers whose passion for their craft is hindered by the work environment. Often kept to “simple” tasks or faced with demoralizing conditions like corporate hierarchies or project death marches, developers find it difficult to maintain their enthusiasm. However, the pattern suggests several strategies to protect and grow this passion.

Reaction:

The pattern could be related to deeply with many software developers who have found themselves in similar situations. It highlights the importance of preserving one’s love for the craft amongst challenging circumstances. What’s really interesting is the acknowledgment that not everyone has the privilege to earn a living through their passion, making it important to safeguard and nurture it.

What’s Interesting and Useful:

The emphasis on working on tasks that align with personal interests stands out as a practical approach. By dedicating time to activities that spark joy, developers can reignite their passion and find fulfillment in their work. Additionally, the idea of seeking out like-minded individuals and immersing yourself in the classics of the field serves as a reminder of the rich heritage and community support available in software development.

Impact on Professional Outlook:

The pattern encourages a reevaluation of how someone approaches their career in software development. It makes individuals prioritize environments that support their growth and passion, even if it means diverging from conventional career paths. Setting clear boundaries and maintaining a sense of wonder about programming, as said by Paul Graham, becomes essential for long-term satisfaction and success in the field.

Disagreements and Reflections:

While the pattern offers valuable insights, some may find it challenging to implement certain suggestions, especially in highly demanding work environments. Setting boundaries and steering conversations towards positive topics require courage and confidence, which may not always be feasible depending on organizational culture and power dynamics. However, the underlying message about the importance of preserving one’s passion remains relevant.

In conclusion, “Nurture Your Passion” serves as a reminder that maintaining enthusiasm for software development is a deliberate effort, especially in the face of adversity. By embracing strategies outlined in the pattern and staying true to their passion, developers can navigate challenges and thrive in their careers.

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

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

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.