Monthly Archives: May 2024

CS-448: Week 14

Retreat into Competence

This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

Conclusion

I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

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.

AI and Unit Testing

With artificial intelligence increasing computational power and variability in usage, I wondered what advances were being made with AI. The tedious and repetitive aspect of test-driven development can sometimes leave the development process stagnating, so I was interested in how AI is changing the software testing process. This blog post, AI for Unit Testing: Revolutionizing Developer Productivity, by Philip Riecks, expands on how AI is improving the quality of our code and the productivity of our developers. 

The article highlights AI’s revolutionary steps in software testing and development. It discusses tools like IDE plugins that act as digital coding assistants and surveys from GitLab that show a significant increase in AI usage and demand for AI testing solutions. Philip explains the benefits of AI, which include streamlining test creation, boosting developer productivity, reducing developer fatigue, and many more. The article addresses why developers hate unit testing, highlighting the importance of it despite its tedious nature. It then gives an assortment of those tools with a small explanation of their specialization.

I found this article very enlightening, especially regarding the impressive abilities of AI-driven tools. My first thought when thinking of AI is to fear for developers’ jobs or worry about copyright infringement. It is nice to see that the focus of AI tools based on this article is to help developers by removing tedious tasks and allowing them to focus on improving the code. One of the sections mention AI’s ability to use user stories to generate test cases automatically. This was particularly interesting to me because a big part of behavioral-driven development involves using user scenarios when developing tests. Having AI take the workload off those using the BDD method would significantly increase productivity.

While reading, I still worry about the experience of those who use AI. If AI predicts defect areas, creates tests, and assists you every step of the way, how will that affect your ability to do those tasks? I also wonder if it matters if our abilities are lowered if we always have the tool at our disposal anyway. I imagine it would end up the same way we use calculators. We learn and can do calculations, but use the tool for convenience. Overall, I’m cautiously excited about AI, the stress taken off developers’ shoulders, and the increased time they will receive to focus on enhancing their projects.  

In the future, I will endeavor to learn more about AI, focusing on current and upcoming tools. When I use these tools, I will use them as an assistant and not as a crutch. 

The Article:https://www.diffblue.com/resources/ai-for-unit-testing-revolutionizing-developer-productivity/

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

CS448 Software Development Capstone – Apprenticeship Patterns – “Confront Your Ignorance”

For my final Apprenticeship Patterns reflection, I want to talk about the “Confront Your Ignorance” pattern in the second chapter, “Emptying the Cup”. In the last sprint of our software development capstone course, I felt that I wasn’t able to deliver my best work – partly because of how undeveloped my unit testing design skills are, and partly because I caught a mild cold partway into the sprint that zapped my energy levels. If I want to be honest though, the former problem was the more severe of the two, and it will stick around far longer than the sniffles I had. I’ve realized how much more I need to study the technologies I’ve been working with. In combination with the “Reading List” and “Record What You Learn” patterns, I want to put this pattern into action over the summer break and establish a disciplined reading and studying habit for software development topics.

In addition to the unit test design, there were other parts of the work I took part in over the semester that I didn’t completely understand before it came time to implement them. Docker is one subject I want to take the time to research in further detail, since it was an essential component of our work. I first encountered Docker last semester, but it wasn’t until this semester that I’ve understood what the purpose and benefits of virtualized containers are. I know now that Docker allows development teams to create applications within a common virtual operating system. What I want to learn more about is how to write docker-compose files to initialize a functional HTTP backend server. One of my tasks this sprint was to do just that for one of the backend microservices in Thea’s Pantry, and I wouldn’t have been able to do that if there wasn’t a complete docker-compose file in another backend that I could adapt for the repository I was working in.

The largest gap that in my knowledge that I’ve been wanting to address is my technical skill with Java. Java has been the language that I’ve accomplished the most with, next to Python, but I haven’t taken the time to write any Java this semester besides the foundations of my MonsterFactory project, which I realize now could qualify as an example of the “Breakable Toys” pattern from the textbook. Over the summer I think I would like to implement my studying of unit test design into the MonsterFactory and create some tests for the abstract factory classes.

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

Walking the Long Road

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.

CS-443: Week 17

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

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.

Static vs Dynamic Testing

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.

Fundamentals of JUnit

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.

Unlocking Success Through Understanding Failure

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.

Sprint #3 Retrospective

What Worked Well:

Sprint #3 was our last sprint as a team and appeared to be one of our easier sprints since we were all familiar with our team workflow, who was doing what, and reviewing processes. In Sprint #3, we were tasked with completing seven different issues for a total weight of 25 points. As a whole, we completed six out of our seven issues for a total weight of 24 out of 25 points. We managed to complete many issues as a team, which was extremely helpful. By combining five minds, we could work in an efficient manner. Something worth noting was our communication this sprint. In all three Sprints, we conducted weekly meetings either in person or over Discord. Additionally, we had weekly standup meetings informing the group with what everyone was currently working on, doing next, or needs help with. I noticed that once we finished one issue, nobody hesitated to start another issue. This helped propel the project forward. Connecting all three sprints, Sprint #1 was a learning process, Sprint #2 was learning how to efficiently work with each other and complete tasks in an effective manner, and Sprint #3 was combining everything we have learned and putting it together. Sprint #3, whether it was our workflow, completing issue process, review process, or communication, we were able to combine everything and find success. One thing I particularly enjoyed was the comments we made on issues. Everyone on the team wrote comments informing the team what was going on within an issue, what the issue needed for completion, and any changes made to contribute.

Improvements As A Team:

We made some drastic improvements from the previous sprints in regards to how we took on work, the time we worked on it, our review process, and much more. Considering this is our final sprint as a team, I believe we are more than capable of bringing what we have learned into the workforce. To continue growing individually on our own teams, I believe it would be important to continuously build on communication. Regardless of the group or team we are on, it’s important to always provide updates, feedback, and details upon what we are working on, completing, any problems, any help needed, and so on. By continuously building on communication, asking questions, and continuing to refine and develop our skillset, we can set ourselves up for success in the future regardless of the team we are on. 

Improvements As An Individual:

During Sprint #3, I was able to work on four different issues. My first issue I completed individually and it was Update and Review InventorySystem/Documentation. This issue required me to go through the different files and add any files, comments, or updates, so that everything was corrected for future sprints. My other three issues I completed with my team included, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryAPI, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryBackend, and Determine what needs to be done for GuestInfoFrontend. For the Verifying issues, these involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes to correct them. For the Determine what needs to be done for GuestInfoFrontend, involved the team building the frontend to view its contents and code. Here we created new issues for future sprints in regards to what needs to be completed, what can be changed or implemented better, and how we can improve the GuestInfoFrontend. For individual improvements, I’d like to continue being more of a team player where I’m open to help and support anyone on my team and voice my thoughts and opinions. Even if it’s just reviewing work and mentioning some tips or ideas, it can be extremely valuable. Additionally, when writing code or fixing documents, I’d like to add more comments. By doing so can allow anyone to understand my thought process while I’m working on issues. It would also allow other people to understand my work and not get lost or confused, allowing for anyone to contribute, add on, or provide feedback on what I’ve completed. Keeping that in mind, I believe it’ll help me grow as an individual and a teammate, and help me in numerous ways with my professional career.

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