A Deeper Dive into Mocking

In class, we began learning about the use of mocking in software testing. After doing an activity, I realized I only slightly understood the purpose of it. So, I decided to investigate, which is when I found The Art of Mocking by Gil Zilberfeld and Dror Helper.

The article begins by giving an introduction to unit tests for those who might not be familiar. They also give an example in C#, which is the language they use for the rest of the article. However, this does not impact information about mocking besides the syntax of the examples.

Once unit tests are covered, hand-rolled mock tests are introduced: they are classes that the developer(s) code which take the place of the real objects for testing purposes. It might not accurately test the system, but it ensures the business logic of the class works. 

The types of mocking listed are those manually made by the developers and those auto generated by mocking frameworks (Mockito or Moq). The article goes quite in depth into mocking frameworks, in their types, what they do, and what to look for when choosing one. Zilberfeld and Helper also discuss the benefits of mocking, which generally boils down to the fact that mocking cuts loose extra requirements for testing, such as databases and other external/complex resources.

Lastly, the best practices and potential hazards are listed. From what I gathered, the important ones were:

  • Only use fake objects when necessary, as too many can create weak/fragile tests
  • Understand what you’re testing and the dependency
  • At most two assertions/verifications per test

I selected this article because I was struggling a little bit with what mocking was and why it was useful. I had somewhat understood the concept and the idea behind it in class, but needed to go on a deeper dive to get a better grip on it. This resource also seems pretty real, in the sense of it feels homemade and focused; all the important stuff is in the articles themselves, not a subscription or anything. 

This article is superb with its examples and clear, in-depth explanations of unit tests and mocking. The formatting is easy to follow and allows for smooth learning and transitions from concept to concept. I personally believe that mocking is quite useful when applied lightly. I learned that Verify should only be used in fake objects when it’s the only way your program can pass or fail; otherwise, it might not matter whether every method actually calls the expected method. 

This affected me in a positive way as it gave me greater insight to mocking and more confidence in my personal understanding as to why we use it. I expect to apply this in a future job when I might need to test a method that uses database information, but it would take too many resources to use the database for testing purposes.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Week 9 – Better late than never.

Jesus, yeah I’ve kinda been slacking on my blog writings huh? So sorry for the radio silence coming from this place. Going forwards I can hopefully write every week moving forwards.

Anyways, for my first time writing for this class with Professor Wurst, being Software Quality and Testing, I wanted to talk specifically more in depth about what I had already sent him earlier this semester in our course’s Discord server, that being a video by Matt McMuscles about Sonic The Hedgehog (2006)

I have personal experience with this game, as I specifically remember going to BlockBuster when it was still around, wanting to get the game LittleBigPlanet, and my father reaching into the the bargain bin to find Sonic 06, as its better known to fans (quite the mouthful the real title is, and better to differentiate it from the original game on Sega Genesis), and handing it to me. Unfortunately, I had left the store only with Sonic 06.

The reason I relate this to Software Quality and Testing, is because this game is a heavy example of what happens when you rush it, as the video shows. This game was rushed out to shelves for the Christmas of 2006, so SEGA could make a good profit off of it, benefitting off of the increased demand that comes with Christmas.

Many things in this game show that it was improperly tested, with bugs, glitches, and even crashes all about the game. The game is held back due to this, as there is a proper and interesting idea underneath the surface. However, the lack of finding these extremely prevalent bugs and glitches lead to this being one of the worst selling titles in the Sonic franchise.

This goes to show why testing and quality assurance is so important, even in the gaming field. Video Games are software after all, just specifically for entertainment and enjoyment.

I specifically wanted to cover this for this class because it shows me why making sure the testing is as fluid as the programming to create a perfect product. This is especially true in the gaming field, which I hope to have a future in.

Needless to say, I don’t own my own copy anymore. I snapped my PlayStation 3 disc a long time ago. And months after I got it, I did end up getting LittleBigPlanet, and played it way more than this travesty.

tl;dr dont get the game in bargain bin.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Being the Least Skilled: Good or Bad?

The “Be the Worst” pattern advises individuals to seek out environments where they are not the most skilled or knowledgeable. Instead of always aiming to be the best, this pattern encourages embracing discomfort and challenges that come with being the least skilled person in the room. By immersing oneself in such environments, individuals can experience accelerated growth, learning, and personal development.

The “Be the Worst” pattern has profoundly impacted my perspective on professional growth and skill development. It challenged me to rethink the notion of always striving to be the best and instead highlighted the immense value in stepping into situations where I may feel inadequate or outmatched.

What resonated with me the most about this pattern is its emphasis on humility, openness to learning, and the willingness to embrace discomfort. It acknowledges that growth often occurs outside of one’s comfort zone and that being the least skilled person in a group can be a powerful catalyst for improvement.

This pattern has caused a significant shift in how I approach my intended profession as a software developer. Instead of seeking validation from being the best, I now prioritize seeking environments where I can learn the most, even if it means initially feeling uncomfortable or challenged.

One aspect that I found particularly thought-provoking about this pattern is its recognition of the importance of humility in learning. It encourages individuals to set aside their ego and embrace the learning process fully, regardless of their current skill level.

While I wholeheartedly agree with the premise of the “Be the Worst” pattern, I also recognize the importance of finding a balance. It’s essential to have supportive environments where one can leverage their strengths while still being pushed to grow and improve.

“Be the Worst” pattern has inspired me to embrace challenges, seek out learning opportunities, and approach skill development with a mindset of continuous improvement. It has reshaped my perspective on professional growth, emphasizing the value of discomfort and humility in the journey towards mastery.

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.

Week 7 blog

HI everyone, welcome back to my blog. In this post, I will be talking about two patterns from the apprenticeship patterns book that was provided to us in the beginning of the semester. We will be going to go more in depth about how you should reflect as you work and how to record as you work, which I think goes hand in hand in my opinion. First, let’s talk about recording what you learn. There is this saying that my dad always used to tell me was that those who don’t learn from their mistakes are the ones doomed to repeat it. There are a lot of things that you can do to help you with that. For example, you can start recording your journey of what worked and what doesn’t in a sort of blog or personal journal. I know some people who write those things down and never go back and read them ever, what’s the point? Don’t just write it down, try to think about it and review it later, just to freshen up. You never know, you might discover something new or old that will help you and will help you avoid making the same mistakes again. I personally do not write anything down and I have a terrible memory, so I should probably start writing things down, and it will help me get better by giving myself something to look forward to and learn from.

The second pattern I want to go over is the ability to reflect as you work. Ask yourself questions, like how did I get here or how can I improve? It doesn’t have to be questions about yourself, you can say how can we improve as a team? This will make you observe and reflect on things about yourself and the environment around you. I believe that this goes hand in hand with the first pattern because you can observe yourself and ask questions regularly and then write the conclusion down of what you have learned from this experience. Personally, I will start my own daily private journal so I can be constructive with myself and honest to try and improve my everyday life.

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

The Happy Path

Testing code and software can come in many different forms, some may be better than others. In this post, we will look at path testing, or happy path testing. Path testing is representing your code in a linear graph, using nodes and arrows. The nodes represent lines of code, and the arrows dictate the flow of the code or program. It’s a fairly straightforward way of testing, depicting how you want your code to flow, and how the code actually flows. It can help you visualize the execution of your program.

In this blog post, it talks specifically about happy path testing, which is described as “a technique that tests the application through a positive flow to generate a default output,” or “a type of software testing that focuses on the most common and expected scenarios that a user will encounter when using an application.” Essentially, it allows you to see how your code executes in a typical environment. In the blog post, the example of an online shopping site is used, where the typical flow would be a user visiting the website and browsing through the products, adding some products to their cart and going to checkout, entering their shipping address and payment details, and finally finally receiving a confirmation and an email. That’s the happy path the website takes when a normal user goes to shop. This kind of testing ensured that nothing wrong occurred when it came to a normal execution. This is the same thing that happens when applying this testing strategy to your code, going through your code in a normal, typical situation and making sure you will not run into bugs and errors. Some steps to perform happy path testing effectively would be defining the scope and objectives of the testing, designing the test cases and scenarios, executing the test cases and scenarios, analyzing and reporting the results and outcomes, and fixing and retesting the issues and defects. The post also talks about the opposite of happy path testing, and some challenges when it comes to this kind of testing, such as overlooking negative and edge cases and relying on the happy path as a final verdict.

Although happy path testing is an effective testing strategy, it only covers the main part of your code, leaving some areas vulnerable to possible bugs and errors that may not be picked up or detected. But even with that, this is good for an initial testing strategy. It allows you to confirm that your code works as intended and expected when it comes to the most common scenarios of your code. Personally, I’m a fan of this kind of testing, being able to visualize the way my code works is nice. However, I know its limits and when it is effective and when it is not.

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

Success Begins By Sweeping The Floor

In the Software Development industry, every journey begins with a step forward and is often in the form of menial tasks. The Sweeping the Floor pattern emphasizes the importance of starting off small and embracing humbling tasks as a newcomer to a team. This means volunteering to do simple yet essential tasks to help contribute to the team’s overall success and grow as a developer. These tasks may not seem as exciting, but they help form the backbone of the team and provide valuable learning opportunities.

While learning more about the pattern, I found myself reflecting on my own experiences. This pattern brings up the idea that we should try to tackle not just simple tasks, but challenging ones as well. This helped me realize that regardless what our level of knowledge is, every contribution matters and serves as a stepping stone towards future accomplishments.

In a field that is often associated with complexity and innovation, I found it interesting for a pattern to highlight the importance of starting from the ground up and acknowledging that mastery is a journey that comes with time, rather than a destination. Also, by taking on tasks within our teams, we are gaining additional knowledge. The patterns focus on filling knowledge gaps through hands-on experience and learning underscores the importance of practical learning in the field.

Sweeping the Floor has led me to reevaluate my approach to the field. While I have always recognized the importance of continuous learning, this pattern has reinforced the idea that no task is beneath us as craftsmen and apprentices. This helped inspire me to contribute more to any team I’m on, even if it means taking on some of the more challenging tasks.

While I agree with the message of the pattern, I believe there’s a fine line between taking on humbling tasks and being pigeonholed into a role with limited growth potential. I believe it is essential to seek opportunities for growth and development beyond just menial tasks. While Sweeping the Floor is a part of the apprenticeship journey, it’s also crucial to strike a balance and demonstrate knowledge for more significant challenges and roles within a team.

With this being said, the Sweeping the Floor pattern can serve as a reminder that with dedication and continuous learning, we can follow our own paths to mastery. By embracing the humbling tasks from the beginning rather than pushing them away, and reaching for various opportunities for growth, we as apprentices can then lay a solid foundation that’ll set us up for success in the future.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches: Nurturing Your Passion for Software Development

In a world where promotions often signal success, it’s crucial to consider whether ascending the corporate ladder aligns with your true passions. George Leonard, in his book “Mastery,” cautions against succumbing to the allure of quick-fixes, urging us to stay committed to our craft despite the tempting promises of managerial roles.

Summary of the Pattern

“Stay in the Trenches” challenges the conventional notion that climbing the organizational ladder is the only path to success. It emphasizes the importance of remaining immersed in the technical aspects of your profession, particularly in software development, rather than transitioning into managerial roles prematurely. By prioritizing hands-on experience and continuous learning, individuals can sustain their passion for their craft and avoid the erosion of their expertise.

Reaction to the Pattern

This pattern resonates deeply with me as a software developer. It underscores the significance of staying true to one’s passion for programming, even in the face of enticing promotions. The idea that mastery diminishes when one veers away from practice serves as a powerful reminder of the value of continuous engagement with technical challenges.

The pattern prompts me to reconsider traditional notions of career advancement and success within my profession. It encourages a shift in perspective towards recognizing the intrinsic satisfaction derived from honing in on one’s skills, rather than solely pursuing external markers of achievement.

Furthermore, “Stay in the Trenches” has prompted me to reflect on the role of leadership and influence within technical domains. It highlights the potential for experienced practitioners to advocate for environments that facilitate ongoing learning and growth, not just for themselves but for their colleagues as well.

Disagreements with the Pattern

While I largely agree with the principles outlined in this pattern, I acknowledge the complexity of navigating career trajectories within different organizational contexts. While staying in the trenches may be an ideal scenario for some, it may not always be feasible or conducive to professional growth in every situation. In some organizations, the pathways for technical advancement may be limited, and promotions into management roles may be unavoidable for those seeking career progression. Additionally, the pattern’s emphasis on rejecting promotions may not align with everyone’s career aspirations or financial needs.

In conclusion, “Stay in the Trenches” serves as an important reminder of the importance of nurturing one’s passion for software development amidst the attraction of managerial positions. By prioritizing technical excellence and continuous learning, individuals can navigate their career paths with intentionality and authenticity, ultimately fostering a deeper sense of fulfillment in their professional challenges.

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

Decision Tables from a Template

Over the past few weeks in CS443 – Software Quality Assurance and Testing, we’ve been learning how to apply our boundary test classes to create Decision Tables and apply somewhat similar logic to create Program and DD-Path Graphs for code segments. Decision tables are visual tools used in software testing and analysis to specify actions based on given conditions. The strategy we learned in class of assessing all possibilities then systematically combining them based on the decision outcomes and particularly “Don’t care” scenarios seems like a useful and interesting way to map out test designs.

So, I decided to look into blogs discussing Decision Tables and their implementation in software testing and found a great post on ShiftAsia with abstract and specific examples alongside general discussion. This post is also quite recent – posted on January 9, 2024 – which is something I always appreciate as the software/tech world is constantly changing. It opens by describing how to create a Decision Table by representing it with the following matrix:

Condition Stub Condition Entries
Action Stub Action Entries

Condition stub: List of all conditions in consideration

Condition entries: Filled out with Y/N (or X) to cover all possible combinations of conditions

Action stub: List of all possible actions/output

Action Entries: Marked (generally with X or blank) to show outcome and an association between a condition and result.

This is then illustrated with an example of being able to register according to conditions of having a valid email, registered email, and valid password. I found this template and example helpful to better understand Decision Tables in general by comparing them to the steps we did in our In-Class Assignment 7. And, using the example of an altogether invalid email forcing all results to be “Invalid” makes sense logically for the column consolidation.

The process of combining columns and simplifying Decision Tables is reminiscent of CS254 – Computer Architecture and Organization concepts, particularly using K-Maps to calculate Sum of Products and Product of Sums. Based on similar responses to a variety of inputs, we are able to essentially combine and simplify the K-Map table and in turn the expression it produces. While K-Map logic works based on binary math laws rather than actual outcomes, there’s a clear correlation here as we represent outcomes with boolean values that can be easily represented in binary – as either a 0(false) or 1(true). My personal experience in CS254 wasn’t the best – I didn’t totally understand how many of the concept we learned are applicable in practical situations, so it’s cool and exciting to see it applied in software testing – an area I would’ve probably least expected it.

Sources:

https://blog.shiftasia.com/use-decision-table-in-software-development

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

CS Blog Post 1

Breakable Toys is a pattern that shows the importance of learning through failure and trail and error in software development. It teaches that failure is inevitable in the learning process and encourages developers to create small,  projects where they can make mistakes without breaking something permanently . By building a toy systems with similar toolsets to their professional projects but on a smaller scale developers can push their abilities to the limit and gain experience. The pattern suggests building simple projects like wikis, calendars, or address books. These projects serve as opportunities to try out new ideas and techniques without the pressure of real-world consequences in a job scenario . They allow developers to learn from their mistakes, iterate, and grow as professionals. Examples of Breakable Toys include personal wikis, games like Tetris or Tic-Tac-Toe, blogging software, and IRC clients. The idea is to choose projects that are relevant and useful to the developer’s life, allowing them to invest time and effort into exploring different aspects of software development. The pattern also emphasizes the importance of enjoying the process of building these toys. If the projects become stressful, they are less likely to be learning experiences that are successful.Also , developers should be open to the possibility that their toys may evolve into something more significant or even gain other users over time. A classic example cited is Linus Torvalds’s creation of Linux, initially announced as a hobby project to build a small operating system similar to Minix. This shows how even the most significant projects can start as personal experiments or Breakable Toys. Overall, Breakable Toys encourage developers to embrace failure, take risks, and continuously seek opportunities for learning and growth in their craft. By building and iterating on these small projects, developers can expand their skill sets, deepen their understanding of tools and technologies, and ultimately become more proficient practitioners of software development. I have used breakable toys for a school setting but never for just for fun, after diving more to the pattern I will be deepening during my free time. 

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Navigating the Nuances of Mock Testing: A Reflection

In the realm of software engineering, particularly within the course content of CS-401, the concept of mock testing stands out as a pivotal technique in the landscape of software testing methodologies. Recently, I delved into an insightful resource on mock testing https://www.geeksforgeeks.org/software-testing-mock-testing/ , which offered a comprehensive exploration of its applications, benefits, and best practices.

Why This Resource?

Choosing this article stemmed from my quest to understand the intricacies of unit testing, especially how mock objects can simulate the behavior of real dependencies. The clarity and depth of the article provided a solid foundation, aligning perfectly with our coursework on advanced software development practices.

Insights Gained

The article elucidates mock testing as a technique where simulated objects, or “mocks,” replace system dependencies. This isolation allows for the rigorous testing of individual components without the overhead or unpredictability of their real counterparts. Notably, the piece highlighted the distinction between mocks, stubs, and fakes, demystifying their respective roles in a testing environment.

Personal Reflection

Engaging with the material, I was struck by the elegance of mock testing in decoupling code, facilitating a cleaner, more modular design. The practice of defining expectations for mock objects not only enforces a contract between different parts of a system but also embeds a level of documentation within the test itself. Reflecting on past projects, I recognize instances where a lack of isolation complicated both the development and testing phases. Moving forward, I’m keen to apply mock testing more judiciously, ensuring each component can be tested in isolation, thus enhancing test reliability and code quality.

Applying What Was Learned from this Resource

In future software projects, I plan to leverage mock testing to streamline the development process. By isolating external dependencies and focusing on the behavior of the system under test, I anticipate a more efficient debugging and validation process. Furthermore, the insights gained on best practices will be instrumental in avoiding common pitfalls, such as over-mocking, which can obscure the clarity and purpose of tests.

Conclusion

The exploration of mock testing through [Resource Title] has been both enlightening and validating, reinforcing the relevance of mock testing within our CS-401 curriculum. As the software complexity grows, so does the necessity for sophisticated testing methodologies. Mock testing, with its promise of isolation and focused validation, is a technique I look forward to mastering and applying in my journey as a software developer.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.