In a previous blog post, I had talked about Test Driven Development, or TDD. Today, I’m going to introduce a different approach that aims to almost rectify the potential shortcomings of TDD, that approach being Behavior Driven Development, or BDD for short.

BDD can be described  as “a collaborative approach to software development that aims to bridge the communication gap between business and technical teams” with the core idea of creating a “shared understanding of the software’s intended behavior using concrete examples” (Test Guild).

“The process revolves around writing scenarios using the Given-When-Then format, which describes the preconditions (Given), the action or event (When), and the expected outcome (Then).” This is a format that can be easily understood regardless of what people specialize in. TDD involved writing test cases and coding based on those test cases which mainly involved the developers, testers, and those that are closely linked to the programming and technical development. BDD, on the other hand, can involve the non-technical, such as stakeholders and those from other departments on top of the developers and testers. It can be simply put as, “compared to test-driven development (TDD) which is developer-centric, BDD is a team-wide practice” (Test Guild).

The Given-When-Then format allows for less misunderstanding when it comes to what is required of the software. Developers may use names that are short and to the point to describe something but it doesn’t match the behavior that is desired. The same developer or others that have just started working on the code may simply go along with it not realizing that what is desired of the code is something more or something else entirely. By using this format along with full sentences describing exactly what the code should do, there will be less room for error, misunderstanding, and time wasted fixing the code down the line.

One of the difficulties that seems to arise with the implementation of BDD is the inclusion of implementation details in scenarios. This is because scenarios are meant to focus solely on behavior. Including implementation details is basically attempting to set something in stone; scenarios describe what is desired of the code and how developers achieve that can change many times. It ends up adding more work every time that detail has to be met or changed.

BDD is an interesting topic, it seems to be a direct upgrade from TDD but that isn’t always the case. Take a classroom environment for example, it’s a bit odd as we (the students) could be considered developers but what about the other roles in the process? Would the professor act or technically be a stakeholder? It’s a process that can be learned at any point but it seems it can be only truly put into practice in a real world environment. We can certainly take aspects of BDD into mind, the Given-When-Then format and basing development around desired behaviors seems to have little to no downsides for any situation. 

Source: https://testguild.com/what-is-bdd/

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

The “Breakable Toys” pattern offers a solution to a common problem faced by software developers, which is the lack of opportunities to learn from failure in a professional setting. The purpose of this pattern is to create a safe environment where developers can experiment, make mistakes, and learn without fear of repercussions. By building toy systems that mimic real-world settings but with reduced scope and complexity, developers can gain valuable experience and develop their skills more effectively.

The intriguing thing about this pattern is its emphasis on the importance of failure in the learning process. In many industries, including software development, there’s often a stigma attached to failure, which leads to a culture where taking risks is discouraged. However, this pattern changes that mindset by suggesting that failure is not only acceptable but also a necessary step toward growth and improvement.

As someone whose goal is to become a software developer, this pattern has certainly changed my perspective on my approach toward learning and skill development. It highlights the value of creating a learning environment that prioritizes experimentation and iteration over perfection. This helps get rid of the fear of failing and being afraid to make mistakes, and now I see them more as opportunities to grow and learn.

One of the aspects of the pattern that resonates with me is the idea of “budgeting for failure”. By allocating time and resources to build and experiment with breakable toys, developers can proactively invest in their own professional development. This proactive approach to learning is essential in this industry due to the continued growth and evolution, where adaptability and continuous improvement are key to success.

While I do like this style of thinking, I can also see potential challenges in implementing this pattern in a corporate environment that may prioritize productivity and efficiency over learning and experimentation. Convincing management or team leaders of the benefits of breakable toys may require a shift in mindset and a willingness to embrace a culture of learning and innovation.

Overall, the Breakable Toys pattern offers a refreshing perspective on how to approach learning and skill development in software development. By creating a safe space for experimentation and failure, developers can cultivate a growth mindset and become more resilient and adaptable in the face of challenges.

5. Perpetual Learning | 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.

The blog post “Software Testing Basics: Positive vs. Negative Software Testing” explores two fundamental approaches in software testing: positive and negative testing. I chose this blog post because this semester we have been taught a variety of software testing techniques and strategies. From this blog post, it has categorized some of the techniques we have learned into one of two categories mentioned, positive or negative testing. I found this useful as it also allows us to know easily when to utilize certain techniques for certain scenarios.

The blog begins by describing the significance of software testing in ensuring the quality and reliability of software applications. Testing is important not only to detect bugs but also to enhance user experience and maintain credibility. Positive testing involves validating the software’s expected behavior under normal conditions. Test cases are designed to verify that the system functions as intended when provided with valid inputs. This method aims to affirm that the software performs its functions accurately and efficiently. By executing positive tests, developers can gain confidence in the system’s reliability and usability. On the other hand, negative testing focuses on the software’s ability to handle invalid or unexpected inputs and conditions. Test cases are designed to provoke errors, exceptions, or failures within the system. This approach aims to uncover vulnerabilities, defects, or unforeseen scenarios that may compromise the software’s performance or security. Negative testing is crucial for identifying weaknesses and enhancing the robustness of the software.The blog emphasizes the complementary nature of positive and negative testing. While positive testing validates the correctness of the software’s intended behavior, negative testing uncovers potential issues that might have been overlooked. Together, they provide comprehensive test coverage and contribute to the overall quality assurance process.Moreover, the blog discusses various strategies and techniques for conducting positive and negative testing. For example, positive testing involves scenarios such as input validation, boundary testing, and functional testing, where the focus is on confirming the expected outcomes. While, negative testing encompasses techniques like boundary value analysis, error guessing, and stress testing, aimed at challenging the error-handling capabilities of the code.

After reading this blog post, I feel like I would be better prepared for software testing or quality assurance. The descriptions of positive versus negative testing in my opinion were very helpful in solidifying my knowledge on software testing as well as teaching me new aspects of it. As previously mentioned, the blog post was beneficial for teaching me to know when to utilize certain techniques for various scenarios.

https://www.testmonitor.com/blog/software-testing-basics-positive-vs.-negative-software-testing

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano 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 “Expose Your Ignorance” pattern discussed in chapter 2 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 think being able to show that you don’t know everything and can have confidence in learning is essential to growth, both professionally and personally.

This section of the chapter discusses that learning is an essential part of the development process. “Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow. According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. These societies are increasingly dependent on your competence as a developer, as software creeps ever-deeper into our everyday lives. Yet because of your inexperience, you have many zones of ignorance. You are in a bind. The people around you—your manager, your client, your colleagues, not to mention yourself—are all under tremendous pressure to deliver software. You can see the need for confidence in people’s eyes when they ask you how long feature X will take you to finish. There can be tremendous pressure to pacify them, to reassure them that you know precisely what they want, how you’re going to give it to them, and when.” The need to appear completely in control and competent when you are new is a very difficult instinct to let go of, but it is essential to free yourself of it if you want to progress.

You must be honest with your colleagues and clients, don’ just tell them what they want to hear because what they want to happen might be impossible. “Software craftsmen build their reputations through strong relationships with their clients and colleagues. Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships. Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t. In this way, your reputation will be built upon your learning ability rather than what you already know.”

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.

In this week’s blog post, I will be discussing the “Concrete Skills” pattern discussed in chapter 2 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 think being able to supplement your knowledge with practical abilities will show to future development teams that you can be a helpful addition to the teams.

The first part of this section talks about how some of the first concrete skills that you will learn will mostly entail navigating HR and team assignments, and being able to assure your team mates that you won’t need constant supervision. “Acquire and maintain concrete skills. Even though one of the things that an apprentice brings to a team is an ability to learn quickly, the possession of discrete and demonstrable ability with specific tools and technologies increases the likelihood that you will be trusted to contribute indirectly until you start to gain stature. Some of the concrete skills you should acquire will be little more than mechanisms to get you past crude HR filters and managers who construct teams by playing buzzword bingo. Others will reassure your prospective team members that you can be put to good use and will not require “day care” (Organizational Patterns of Agile Software Development, p. 88). Examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.” Being able to show your fellow developers that you can stand on your own with development is a very important aspect of joining new development teams, but you must be able and willing to ask for help when you need it. The next section mentions something briefly that I think is incredible important, being able to quickly and effectively show an interviewer your concrete skills.

Being able to quickly and succinctly describe your concrete skills in a technical interview is essential. “The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of Your First Language will help establish your credibility and should prove to be extremely useful to your team.”

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.

In this week’s blog post, I will be discussing the “Unleash Your Enthusiasm” pattern discussed in chapter 2 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 think being able to properly and effectively hone your energy to be the most productive is an important skill.

The article first discusses how a new hire’s enthusiasm can be unintentionally forced down by the new hire in order to try to fit in with the development team. “Despite (and because of!) your inexperience, you bring some unique attributes to your team, including an infectious enthusiasm. Do not allow anyone to dampen your excitement for the craft—it is a precious commodity and will accelerate your learning. As a software developer, you will inevitably work as part of a team. In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether, or allow it to manifest only outside of their day jobs.” While this is a natural reaction, it is important to be able to know when to show some of this passion to your team because, your passion is infectuous and may be able to help with team morale.

You must be careful however, depending on the team showing too much passion may work against you. “There are certainly risks involved in unleashing your enthusiasm on an established team. If morale is low or if the team is not welcoming of newcomers, you will likely get some eye-rolling behind your back. You could certainly make a poor impression on people who value competence more than learning ability, particularly when you expose your ignorance. Like any pattern, this one should not be applied blindly. Team dynamics should always be considered. If you find yourself on a team that does not accept your excitement, you will need to find ways to nurture your passion. “

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.

What is JUnit?

JUnit is a Java testing framework that simplifies writing reliable and efficient tests. It’s especially suited for testing Java applications and offers features like multiple test cases, assertions, and reporting. JUnit is versatile and supports various test types, including unit, functional, and integration tests.

JUnit and Testing Types

JUnit primarily focuses on unit testing but can also handle functional and integration testing. Functional tests evaluate the functionality of a system as a whole, while integration tests assess how different components of a system work together.

How Does JUnit Work?

JUnit works by allowing developers to write tests in Java and run them on the Java platform. It provides features like assertions to verify expected behavior, test runners to execute tests, test suites to group related tests, and reporting tools to analyze test results.

Benefits of Using JUnit

• Organized and readable code.
• Early detection and fixing of errors.
• Improved software quality.
• Increased efficiency in the testing process.

Getting Started with JUnit

To get started with JUnit, developers can access tutorials, documentation, and forums for guidance. Setting up a JUnit project involves installing JUnit in an IDE like Eclipse or IntelliJ IDEA, creating a standard test file, and writing test methods.

Writing Test Methods

Writing a test method involves adding annotations, method signatures, method bodies, and assertions. Assertions like assertEquals, assertNotNull, assertTrue, and fail are essential for verifying expected results.

Creating and Running Tests

Creating and running tests in JUnit requires opening the project in a testing framework, selecting the desired test classes or methods, and executing them. Debugging modes like JDWP and Standard Streams help identify and fix issues during testing.

Troubleshooting Techniques

Troubleshooting techniques include using debuggers, checking documentation and forums, and running tests regularly. Well-written tests follow guidelines like keeping them small, relevant, and well-organized.

JUnit’s Assertions

JUnit’s assertions play a vital role in testing by checking conditions and verifying results. Common assertions include assertEquals, assertNotNull, assertTrue, and fail.

Conclusion

JUnit is a powerful Java testing framework that helps developers create reliable and testable code. By incorporating JUnit into their development process, developers can improve software quality, increase efficiency, and ultimately enhance their Java development skills.

Source – https://www.headspin.io/blog/junit-a-complete-guide

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

The Problem of Short-Term Thinking

In today’s fast-paced world, there’s immense pressure to pursue high-paying jobs and quick promotions. The allure of immediate rewards often overshadows the value of long-term growth and expertise. Many aspiring software developers find themselves torn between the desire for mastery and societal expectations.

The Solution: Embrace the Long Road

The path to mastery in software development is not a sprint but a marathon. It requires dedication, patience, and a willingness to prioritize learning over short-term gains. Embracing the long road means understanding that mastery is a lifelong journey, not a destination.

Planning for the Journey

To embark on the long road to mastery, one must be prepared for the challenges and rewards that lie ahead. It involves valuing learning opportunities and skill development over immediate financial gains. Ron Jeffries et al. emphasized that becoming truly good at programming is an ongoing enterprise of learning and practicing.

The Joy of the Journey

While the road to mastery may seem daunting, it offers a rich tapestry of experiences and opportunities for growth. As an apprentice, one learns to wield knowledge and technology like a seasoned samurai, mastering the art of problem-solving and building strong relationships with customers.

The Role of Self-Assessment

Accurate self-assessment is crucial on this journey. It involves recognizing one’s strengths and weaknesses, understanding the depth of one’s knowledge, and constantly striving for improvement. Transitioning from apprentice to journeyman is just the beginning of the path to mastery.

The Ever-Evolving Craft

Software development is a complex and dynamic field, constantly evolving with new technologies and challenges. While the tools and platforms may change, the deeper truths of the craft remain constant. The long road teaches craftsmen to transcend specific technologies and focus on solving fundamental problems.

Charting Your Course

To navigate the long road to mastery, one must envision their future and plan accordingly. By imagining the strangest possible roles and experiences they could have in the next few decades, aspiring craftsmen can chart a course for their career that aligns with their long-term goals.

Conclusion

In conclusion, the long road to mastery in software development is not for the faint of heart. It requires dedication, perseverance, and a love for the journey itself. By embracing mastery as a lifelong endeavor, software developers can unlock their full potential and leave a lasting impact on the world of technology.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.