The “Walking the Long Road” pattern goes into the journey of mastering software development, by tracing a new pathway to a summit rather than just conquering the same peak. This pattern reflects the challenges and rewards of pursuing excellence in software craftsmanship over a lifetime. The pattern begins by talking about the common practice of displaying training and achievement certificates as a sign of expertise. It shares the story of a developer named Dave, who relied on such certificates to validate his skills. However, through interactions with amazing developers, Dave realized the depth of knowledge and continuous learning required to become better in software development. One main idea of this pattern is the recognition of software development as a lifelong learning journey. The idea of mastering it highlights the dedication, discipline, and ongoing commitment needed to reach the highest levels of skill and understanding.

The pattern emphasizes the importance of embracing challenges, staying focused on long-term growth, and valuing learning opportunities over rewards or promotions. The impact of this pattern has me want to keep taking the approach of embracing any challenges and enjoy learning more about software development. It changes the idea that mastering software development is not a destination but a continuous process of improvement and exploration. It encourages so many people including me to prioritize learning, experimentation, and embracing the face of challenges. While the pattern talks about a focus on software development mastery, it also shows that different career paths in the industry are valid and beneficial in the long run. It encourages individuals to find a career path that works with their values, passions, and long-term goals, even if it means navigating tough challenges along the way. This pattern has changed my perspective on career development in software development. It has taught me the value of patience, perseverance, and a growth-oriented mindset. It has also inspired me to keep embracing the journey of mastering software craftsmanship with dedication, knowing that every step along the road contributes to a deeper understanding and appreciation of the craft. The “Walking the Long Road” pattern is a reminder of the nature of software development mastery, the importance of learning, and the rewards of staying committed to a path of continuous growth and improvement in software development.

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

Unit Testing

Unit testing is a process in software testing where the smallest functional unit of code is tested. A common practice for unit tests is to first write the tests as code. Then the test code can be run automatically when changes are made. Doing this allows errors to be found, and isolated quickly if a test fails. Automating tests helps to ensure that efforts are focused on coding, rather than running tests.

As stated previously, a unit test is a block of code that verifies the accuracy of the smaller blocks of the code such as a function. The unit test checks that the block of code runs as expected, determined by the developer’s logic. A block of code may have more than one unit test assigned to it, in order to cover the full behavior of the block of tested code.

A block of code cannot be tested using a unit test because a unit test cannot use external data. Therefore the unit test needs to run in isolation. Because unit tests must run in isolation, this helps to improve the design of the code base to ensure that no function relies too heavily on other parts of the system. Doing this prevents code smells which can lead a rigid system due to insufficient modularization.

Unit testing strategies

There are strategies used when creating unit tests to ensure coverage of all test cases. Some of these strategies include error handling and numerous checks such as logic, boundary, and object oriented. Boundary checks and error handling are similar in the sense that they both check the behavior of the system based on inputs that are invalid/outside the expected input range. Object oriented checks ensure that the state of persisted objects are updated correctly. Lastly, logic checks ensures that the system performs as expected given a valid input.

Benefits of unit testing

A major benefit to unit testing is the increased efficiency when testing code and discovering bugs. Whenever the system code is changed, the same set of unit tests are run. If a test fails, it is easy to identify what caused the failure because tests are small and isolated. Therefore, unit tests help catch any bugs before the system reaches production. Another benefit to unit testing is unit tests act as another form of documentation. Unit tests act as documentation because developers can read the tests to see how to code should behave. Having accurate documentation is an important part of software, so that other developers know exactly what the expected behavior of the code is.

Conclusion

This article was chosen because I enjoyed that it explained when unit testing is less beneficial unlike other resources. This allowed me to understand when unit testing should, and should not be used. I enjoyed learning more about unit testing outside of class as it is such as integral part of software development. Therefore, I plan to implement unit testing in future projects to ensure system accuracy.

Resources:

https://aws.amazon.com/what-is/unit-testing/#:~:text=Unit%20testing%20is%20the%20process,test%20for%20each%20code%20unit.

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

Test-driven development is a method that talks about writing tests before writing code. It emphasizes how TDD has changed software development by making testing an iterative, ongoing process rather than an end phase near the project’s end. This blog talks about the TDD process, the roots of agile development, and its cycle of testing, code, and refactoring. As a computer science major understanding modern software development methods like TDD is important. I chose this source to gain more information about TDD’s principles, benefits, and best practices. Test-driven development’s approach to testing aligns with my idea of making sure that my software is high-quality. The source ideas of test-driven development integration with CI/CD pipelines also intrigued me, as it works with the best practices. It shows the idea of TDD, where each cycle starts with a clear testable goal, collaboration, and making sure it’s high quality throughout development. Learning about test-driven development agile principles highlighted the importance of flexibility, customer feedback, and adaptability in modern software development. One key takeaway was TDD’s role in enhancing collaboration between technical and non-technical stakeholders. By aligning development with user expectations and business objectives through clear, testable goals, test-driven development creates communication gaps and ensures that the software meets defined requirements. This topic means a lot to me as effective collaboration is needed for successful software projects.

The blog’s explanation of TDD’s benefits, such as improved design, and lower long-term costs changed the view of its value. Its emphasis on continuous improvement and code quality connects with my ideas of great software craftsmanship. The topic on best practices, including starting simple, writing expressive tests, and building an understandable test suite helps provide changes for applying test-driven development effectively. I plan on applying TDD’s principles and best practices in my future projects. Making sure I start simple, writing expressive tests, and building an understandable test suite are the steps I want to add to my skills. Additionally, integrating test-driven development into CI/CD pipelines for rapid and reliable deployments connects with software development best practices and emphasizes code reliability. This source not only has opened my understanding of TDD but also inspired me to embrace its principles in my software development skills. Reading and learning more about TDD’s principles, benefits, and integration with CI/CD pipelines is interesting. It has given me a deeper understanding of proactive testing, collaborative development, and efficient code delivery. Using a test-driven development cycle and best practices is not just a method. It’s an idea that fosters excellence and reliability in software development. This source has made me want to approach software development with a proactive testing mindset, ensuring quality and reliability in every line of code.

https://circleci.com/blog/test-driven-development-tdd/

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

Software testing is essential in software development, Static and Dynamic testing are two different approaches in software testing that are important in making sure the quality of the software is good. This source goes into detail about these two different testing approaches and their significance in ensuring top-notch software quality. It gives an understandable guide that breaks down the core concepts of both static and dynamic testing, highlighting their objectives, types, automation possibilities, and crucial decision-making factors. I chose this resource because it shows the idea of software testing in a way that’s easy to understand and the difference between static and dynamic testing. Static testing involves reviewing code and documentation before execution, aiming to catch any defects early in the development cycle. Dynamic testing focuses on validating software behavior during execution, ensuring it meets specified requirements and performs as expected in various scenarios. What interested me the most was when to use each approach and how it works in identifying errors. Static testing identifies coding errors early, contributing to improved code quality and easier maintenance. On the other hand, dynamic testing is important for assessing how software behaves in real-world scenarios, performance, and security.

I can see myself using what I’ve learned about static and dynamic testing, I could be using these testing techniques in my future projects and by having a choice on testing before or during the execution of the code. This source emphasizes the possibility of automation in dynamic testing, which aligns perfectly with efficient testing practices. Learning about automation opens up exciting areas for streamlining testing processes and enhancing overall software development efficiency. Static and dynamic testing are important in software development and testing. This source helps show the relationship between those two different approaches and how they contribute to building reliable, high-quality software. Both types of testing are good it just depends on whether you would want to test in the early stages like during code review or the execution of the code. Static and Dynamic testing techniques are vital in software development and they both complement each other by reviewing the softwares quality.

https://testsigma.com/blog/static-testing-and-dynamic-testing/#

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

JUnit is a popular Java testing framework that makes unit testing, test-driven development, and code writing more efficient for the development team. We discussed JUnit extensively in class. I wanted to discuss an article that provides a comprehensive guide to JUnit so those new to it can understand its fundamentals and importance to software development. This article, JUnit: A Complete Guide, by Shinji Kanaiis, is a valuable resource for beginners to JUnit and those who want a brief refresher. 

The article starts by highlighting the importance of reducing the number of defects early in the development process and how JUnit facilitates that through specific and efficient testing. It explains that JUnit can do this because its testing framework allows developers to write tests that target the functionalities of individual pieces of code. Without summarizing the article completely, I’ll briefly list its talking points. The rest of the article describes several aspects of JUnit, the most important being how it works, the benefits of using JUnit, how to install JUnit, JUnit assertions, and a step-by-step guide on making JUnit projects and tests. 

This article gave me an excellent refresher on what makes Unit Testing and, in turn, JUnit necessary. It is a modular type of testing that does not limit you to testing the entirety of your software but allows you to test individual classes and methods. It enables developers to fine-tune their testing process to find bugs efficiently. I also better understood its effectiveness when combined with test-driven development. Test-driven development focuses on testing first and developing code second. JUnit allows for better test-driven development because developers can efficiently test each case, method, and class until their code functions correctly before moving on to development. The article also talks about the vast resources and tutorials that JUnit has due to its popularity and ease of use. This aspect of JUnit reinforced my choice to write about it because it can be an excellent starting point for those new to Unit testing or software development. The explanation of assertions we discussed in class was enlightening, and there were some assertions that I was unaware of. This article was a great refresher on JUnit’s place in the development cycle and what makes it an excellent resource for software developers. 

I plan to use JUnit in future projects and make my code as modular, adaptable, and bug-free as possible. I will also point those new to JUnit towards this article or other resources so they can better understand how to get started.

The article: https://www.headspin.io/blog/junit-a-complete-guide

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

Throughout the long road of lifes, we always strive to find success, but sometimes we may hit roadblocks and fail. Some of us choose to accept those failures and learn from them, but others may neglect those failures and choose to take an alternative route. The Learn How You Fail pattern, emphasizes the importance of embracing failure. Embracing failure is a crucial aspect of not only personal growth but also professional growth. This pattern encourages us to look for our weaknesses and patterns of failure, and instead of avoiding them, accepting and learning from them. If we can gain knowledge on how, why, and what led to our previous failures, we can learn from them, make adjustments, and pave a path to success in the future.

When we think of the word failure, we often think that it carries a negative connotation, referencing setbacks or disappointments. Yet, in our journey as aspiring craftsmen, failure is not just part of our professional learning, it is possibly one of our greatest teachers. We’ve all experienced some sort of failure at some point in our lives. But the most important part of dealing with failure is pinpointing why we failed, fixing it, and taking those issues head on.

I found this pattern to be extremely interesting considering many people give up after they fail. Failure isn’t something that should be feared or avoided. Instead it should be embraced as a catalyst for learning and self development. It underscores the idea that true growth comes from a willingness to confront our failures and adapt. What I find particularly interesting about this pattern though, is its emphasis on self-awareness and introspection. By actively seeking to understand our patterns of failure, we can empower ourselves to make better decisions about our personal and professional development.

After reading more, I was able to connect the pattern to the software development field. In the field, we cannot just expect to find success. Through lots of learning, practice, and trial and error, we can eventually find success. Instead of viewing failure as a setback or embarrassment, I view it more as an opportunity for reflection and growth. I now realize the importance of acknowledging my successes but also embracing my failures as learning experiences. In the future, I plan on having a more proactive approach towards identifying and addressing any of my weaknesses, rather than just ignoring them.

With this being said, the Learn How You Fail pattern, offers valuable insights into the importance of embracing failure as a means of personal and professional development. By learning from our failures, we can ultimately find success in our chosen fields.

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

One of the last types of testing techniques that we learned about this semester is known is Combinatorial Testing. Combinatorial testing is a testing technique that is used for software applications with a lot of different input possibilities and a high complexity. Even if you create a large number of different test cases, you will most likely still miss a test scenario. I’m not the best at explaining what something is, so I did some research in order to find an article that helps describe the aspects of combinatorial testing as well as how to use it and what its benefits are. This website is called testsigma.com

I think that this website does a great job at explaining what combinatorial testing is as well as all of its different benefits. In the article by Shanika Wickramasinghe, it states “Combinatorial testing is a testing method that uses multiple combinations of input parameters to perform testing for a software application. The main goal of combinatorial testing is to make sure that the software product can handle different combinations of test data as input parameters and configuration options.” This means that combinatorial testing takes a bunch of different input parameters, similar to pairwise testing, and uses it to test a bunch of different cases for the program. This can be extremely useful because some of the errors with a program can only be found with specific inputs. I’ve actually had this happen to me before in one of my classes. I wrote a program and testing a bunch of different inputs and they all worked, but when my teacher tried an input I never used, it failed. I think combinational testing is going to be extremely useful for me in the future. I know it seems like combinatorial testing can only be used in certain scenarios so it might be better to not learn it, but it actually has a lot of benefits according to Wickramasinghe:

• Covers a broad range of input combinations using a minimum number of test cases.
• Increases test coverage compared to normal component testing since it always considers multiple input combinations.
• Helps to detect bugs, defects, vulnerabilities, and unexpected outputs that might not be detected during the usual component and regression testing phases.
• Reduces testing effort, cost, and time. (Since combinatorial tests use fewer test cases to cover a wide scope of testing.)
• Identifies issues at the earliest while allowing the team to address and fix those earlier in the software development life cycle.
• Optimizes the testing process by removing unwanted test cases while ensuring that the cost and effort are not wasted on repeating the same test scenarios again and again.
• Helps to test complex software applications with a large number of parameters, settings, and options.
• Reduces the risk of critical defects going unnoticed, which can occur only when handling specific input combinations.

I recommend that everyone tries to use combinatorial testing at least once so they know how it works in case they ever need to use it again in the future to make sure all of their different input possibilities work.

Link: https://testsigma.com/blog/combinatorial-testing/

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.

Throughout the cumulative experience I’ve had with testing, most of it focuses on the program’s logic and ensuring that it yields a correct result. One aspect of testing I have no experience with is security testing. Here one must find flaws within a system/program’s security and report them to developers so they cannot be exploited later in the product’s lifespan. Security testing has much higher stakes than that of unit testing as vital information such as consumer personal information and system source code may be leaked if there is a security breach. Therefore, testing security is of utmost importance when releasing a service to the public, as failing to do so will damage the service’s integrity.

Security testing hosts several different types of tests, each of which focuses on different aspects of a system. The article Security Testing posted by user pp_pankaj highlights the principles upheld by this testing and what each test achieves. Some of these tests, Posture Assessment, I found quite interesting. Posture Assessment combines the testing methods of ethical hacking, risk assessment, and security scanning into one report to provide an overall security posture of a system (pp_pankaj). Each of these subtests has a shared goal of having a hacker, hired by the development team, find security vulnerabilities within their system and report it to the team. Another form of testing I found interesting was social engineering testing. This deviates drastically from what we as programmers come to understand tests as. These are emulated attacks through communication such as email. The purpose of this test is to train developers to avoid suspicious engagement and to find new ways to breach a system without making direct contact. Whether a development team gets successfully breached through the socially engineered test is dependent on the team’s understanding of who they must respond to. A few weeks ago I was researching a data breach that happened earlier this year at Microsoft. Hackers were able to control a testing account and had direct access to employees on the project. From here they were able to obtain information they naturally should not have access to. All of this occurred due to developers not knowing that they must not communicate with a testing account.

A general metric as to whether security testing is vital to a project is to consider whether your product is liable for holding personal information that is not your own. If this is the case, then it’s in the development team’s best interest to uphold their principle of confidentiality and integrity by running security tests throughout the lifespan of your product.

-AG

Source: https://www.geeksforgeeks.org/security-testing/

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

Beyond Unit Testing, there are several ways one may go about testing a developed system. One of these ways is through combinatorial testing. While researching this topic I’ve seen a couple of steps that I’ve taken in testing that match with this testing method. For example, earlier this semester I learned about how behavior tables can help guide Unit Testing by showing what aspects of a program will be covered by one test. Combinatorial testing achieves a similar effect by first taking all possible inputs (from a pool of predetermined inputs) and then creating a set of tests that will test each unique combination from the pool. A source that helped me grasp this topic is Combinatorial Testing by Shanika Wickramasinghe. In this article, Wickramasinghe provides an example of how they would develop tests. It’s important to note that in this example only combinations are created, NOT permutations, meaning that overall much fewer tests would be needed to fulfill a combinatorial test. This does raise a question for future reading of whether there is such thing as “permutative” testing and how that and combinatorial testing differ.

Using combinatorial testing does provide benefits despite the time it may take to achieve a successful test. Combinatorial tests are all designed to try multiple inputs simultaneously, meaning that both single-fault and multi-fault assumptions will be made in a full combinatorial test. Once these tests are complete, the developer can better understand which inputs cause a problem within their code. Additionally, once the pool of potential inputs is determined, the tester will have a set number of tests they must conduct. These tests may find faults in the program that require specific input that the development team may not have accounted for. Through feedback such as this, the development team can resolve the bug and create ways of handling errors caused by unexpected input. These benefits do come with equally heavy drawbacks. Manual combinatorial testing is possible, however the testers may struggle with creating combinations from a larger input pool. A way this can be solved is by using an automated combinatorial tester. It’s important to note that this can be limited by how intensive the tests are on the hardware of the automated tester. Lastly, the combinations that the test may provide could be so random that it’s nonsensical to test such a thing. This becomes an issue of resources which will vary from developer to developer. Ultimately whether one uses combinatorial testing or not is up to the developer. There are some instances where the cost of conducting one of these tests would be beneficial to the development process, but this is not a “one size fits all” type of test. By using some of the team’s resources, whether it be labor or hardware-bound, combinatorial tests will yield meaningful results as to which areas of the program need further testing.

-AG

Source: https://testsigma.com/blog/combinatorial-testing/

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