Category Archives: Software Development

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

For learning about unit testing in C, I consulted this article on the subject:

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below:

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

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

Behavior Driven Development

Behavior Driven Development ( BDD ) is a test practice that makes sure there is good quality by automating test before or during system behavior specification. BDD test focuses on facing scenarios that describe the behavior of a story, feature, or capability from a user’s perspective. When the tests are automated they make sure that the system constantly meets the required behavior.

The Behavior Driven Development Process

The BDD process has three phases to it. The discovery phase, formulation phase, and the automation phase.

1.) Discover phase: This phase is where the user creates the initial acceptance agenda for the feature. This phase is usually done in a collaborative manor, each team member is contributing.

2.) Formulation phase: This phase is where the acceptance agenda sets into detailed acceptance tests, as the backlog item gets closer to implementation. This phase also incorporates specific examples of the behavior.

3.) Automation phase: This phase is where automation tests are automated to run constantly. This is to make sure that the new system supports the new behavior.

Benefits of Behavior Driven Development

1.) Early detection of errors / defects: When you automate tests in the early stages of development process, you can identify and address the issues. BDD allows for the early detection of defects.

2.) Faster Flow and Time: when using BDD, you can reduce the errors, rework, and replan. BDD accelerates the flow of the development process. Developers can produce features / products faster and more efficiently.

3.) Stronger Test Coverage: BDD allows for a more comprehensive test coverage that focuses on the user behavior and scenarios. Both common and edge cases are tested as well.

4.) Clear understanding: BDD can be plain and clear to understand, because specific scenarios are used to describe the behavior from a user’s point of view. This helps the development to fully understand the requirements and whats going on.

Why I chose this resource

I chose this article ” Behavior Driven Development” because it provided a detail look of a very important test method that goes in conjunction with the technical and business aspect of testing. Understanding BDD is important in today’s society of software development, for giving an efficient and more user friendly user products.

Personal Reflection

This article increased my understanding of BDD and the use of it in software development. I learned a lot about how BDD strengthens collaboration and communication between the business side of things and the technical side of things. This helps to ensure that user’s expectations and requirements are met. The new found knowledge will be extremely valuable in my future endeavors because I will incorporate this method in my future projects. This will help to improve the development process and product efficiency and quality. Also, by using BDD I can make sure that all requirements and specifications are met.

The full article is here:

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Static Testing vs. Dynamic Testing

Testing in software development is important because it helps to deliver efficient and user friendly products to the end user. It also provides the developers with a chance to improve upon the product. Static and Dynamic testing are two important techniques used in software development.

Static Testing

Static Testing has various names like Verification Testing, Non-execution Testing, etc. This testing technique is used to identify defects in software without actually executing the code. This method usually includes manual and automated evaluation of the software and the code. Developers use this method usually in the beginning stages of the development process to catch issues early on, which will also lead to be easier and cheap to fix. This method focuses on reviewing the test cases, test scripts, test plans, and source code.

Static Testing Techniques

1.) Informal Reviews: Developers review each of the documents and give feedback

2.) Walkthroughs: Someone presents the product to the team and someone else takes notes.

3.) Technical Reviews / Code Reviews: review the technical specifications and the source code to make sure everything meets the requirements and standards.

4.) Inspection: Check for defects. Developers usually review the process with a checklist to help identify and record for defects.

Dynamic Testing

Dynamic Testing is a technique that analyzes the dynamic behavior of the code by actually executing it. This method makes sure to check that the software functions correctly and that there are no underlying issues / conditions. Sometimes developers use this method in conjunction with black box or white box testing to provide more realistic results.

Dynamic Testing Techniques

1.) White Box Testing: Examines the internal code structure. You need to actually have the internal code (source code)

2.) Black Box Testing: Checks the functionality without the actual internal code (source code) .

Benefits of both Static Testing and Dynamic Testing

1.) Early detection of defects

2.) Cost efficient

3.) Showcases runtime errors

4.) Reliability

Why I picked this Resource

I chose the article “Static Testing vs. Dynamic Testing” because this article gave me a more detailed and in depth look between two very important testing methods that are currently being used in todays society. It is very important to understand these two testing methods in the software development process because they can deliver efficient and user friendly products to the end user. This article also aligns with what we have learned in the course, making it relevant to talk about and to understand.

Personal Reflection

This article deepened my understanding of static and dynamic testing. I was able to learn a lot about these two testing methods that I did not know, even the many benefits that each method has. Knowing how crucial these two methods are in the software development process and what I know now, this knowledge will help me on my future endeavors when approaching new projects in regards to testing .

The full article is here:

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Test Doubles

Test doubles are a very important tool in software testing. Test doubles allow for users to break off a portion of their code to test specific parts and functions. This helps because users can do this without depending on the other factors within their code. Test doubles are substitutes, they copy the behavior of real objects. This helps to make sure that the tests remain structured and efficient.

Overview of Test Doubles

For this blog post, I chose the Article “Test Doubles: Mocks, Stubs, and Fakes Explained” by Martin Fowler. The article talks a lot about the overview of the different types of test doubles, their roles, and how they can be used in testing.

Types of Test Doubles

1.) Dummy: A dummy object is required for the creation of another object required in the code. Dummy objects will never be used in the test, they are simply like place holders to satisfy the code and its requirements.

2.) Fake: A fake is an object that will always have the same return value. This object is useful for testing certain scenarios, like a user that is logged in or in a consistent database response. They are simple implementations that are not that suitable for production but are good for testing.

3.) Stub: A stub will provided predetermined responses to method calls. Stubs usually imitate the behavior of external components like databases or web services.

4.) Spy: A spy will record information about the interactions with the object being under tests. This helps verify interactions and make sure there is the correct behavior in method calls.

5.) Mock: A mock can be a more advanced test double that will allow for dynamic behavior based on the test scenario. They verify interactions and can change behavior based on conditions. They are useful for ensuring that certain methods are called with specific parameters during the test.

Benefits of Using a Test Double

1.) Early detection of errors/issues: Using Test Doubles will help the users to find any issues within the code. This helps with reducing the risk of defects in production

2.) Cost Efficiency: Using Test Doubles will significantly help to reduce the costs that will come with fixing the issues later in the development process.

Why I Picked this Resource

I chose this resource for the blog post because it provided an in depth overview of the various types of test doubles and their specific role within testing. This article’s contents had some similarities of what we discussed in the class, making it relevant and valuable.

Personal Reflection

This article not only increased my understanding on the topic of Test Doubles, but it also showed my how unique and important each one can be in regards to testing. I also learned the various benefits of these test doubles, so when I choose one in my future endeavors I will know which one will benefit me the most.

In my future endeavors, I plan on using what I have learned about these Test Doubles objects by implementing them on future projects. This new found knowledge will help me to make better decisions in the future and will also improve the quality of my work.

The full Article is here:

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

Elevating Code Reviews: Practical Tips for better Collaboration

Code reviews are a vital part of the software development process, serving as a checkpoint to ensure quality, foster knowledge sharing, and mitigate future issues. Drawing on practical advice from a stack overflow blog article (found here) this post explores how to elevate the practice of code reviews, enhancing their effectiveness and the collaborative environment they create.


The article from stack Overflow provided insightful tips on improving code reviews, emphasizing the importance of constructive communication and efficient processes. It suggest setting clear goals for reviews, such as catching bugs, ensuring consistency, and mentoring junior developers. Techniques like keeping comments clear and actionable, prioritizing empathy and understanding, and maintaining a balance between criticism and praise are highlighted as crucial for productive reviews.

Reason for selection

I chose this article because effective code reviews are essential for any development team aiming to produce high-quality software. As our coursework often involves collaborative projects and peer reviews, applying these enhanced practices can significantly benefit our collective learning and project outcomes.

Adding to the reasons for selecting this article, another compelling aspect is its relevance to the ongoing discussions in our software development courses about maintaining high standards in coding practices. As someone who has been part of several projects and observed firsthand the impact of well-conducted code reviews, I recognize the value in learning and sharing effective review techniques. This article not only enhances our understanding of best practices but also equips us with the tools to implement them effectively in our work, making it an invaluable resource for any aspiring software developer eager to improve their craft and contribute positively to team projects.

Personal reflection

Reflecting on the article, I appreciated the emphasis on empathy and clarity in communication. In past group projects, I’ve seen how negative feedback can demotivate peers, whereas constructive and positive communication can enhance team dynamics and improve code quality. This article reinforced the idea that code reviews are not just about finding errors but also about building a supportive team culture.

Application in future practice

Armed with these enhanced practices, I plan to apply the article’s recommendations in upcoming projects, particularly those involving teamwork. Emphasizing clear, empathetic feedback and leveraging tools for automating mundane aspects of code review will allow me and my peers to focus on more complex issues, thus improving our efficiency and the quality of our work.


Effective code reviews are more than just a quality assurance step; they are a cornerstone of a collaborative and learning-focused development environment. The tips provided by the Stack Overflow article offer valuable guidance on making good code reviews even better, ensuring that they contribute positively to both project outcomes and team dynamics. As we continue to engage in more collaborative projects, these practices will be essential in shaping how we approach code reviews and interact as a development team.


From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

CS448 – Sprint 3 Retrospective

Last Tuesday, we concluded our final of three sprints for CS448 – Software Development Capstone marking the end of the semester/course aside from our final presentations and the ‘capstone’ to my undergraduate Comp. Sci. degree. This sprint and throughout the semester, my team demonstrated exceptional cohesion and proficiency as we learned new skills and frameworks, tackled challenges, and grew together. At the end of last sprint, we still had a few issues with some of the configuration files in the frontend repo we’ve been focusing on: CheckoutGuestFrontend which were causing Pipeline failures. So, we began this sprint by focusing on getting the pipeline straightened out and then moved into strategizing front-end testing frameworks and implementation after having discussed these topics last sprint with

Team 2.

As a team, we managed to finish all of our tasks for this sprint and come to a tidy/clean close to the semester and Thea’s Pantry project. We split the four .vue files which we needed tests developed for up by person, but all helped each other get the first one/configurations sorted:

‘Fix Pipeline for Frontend’ – As mentioned, there were some issues with the pipeline from our additions and designing of the .vue frontend files for CheckoutGuestFrontend in merging our additions. So, we started off this sprint by focusing on this; we did a group code review sharing screen and we were able to work as a team to identify and resolve the problems, passing the pipeline when we finished.

‘After discussing with Team: 01-02, strategize Front-end test implementation’ – After resolving the pipeline issues (and having met with Team 2 to discuss frontend testing), we came back together as a group to strategize how we will go about implementing tests for the various components of CheckoutGuestFrontend. This resulted in creation of four new issues for our board, each representing the task of coding and implementing tests for one of the four .vue files in our repo – planning for one to be addressed by each team member.

‘Test Layout.vue (most cases)’ – The .vue file which I worked on from our repo was Layout.vue. This is arguably the largest/most complicated of our files containing code for most of the objects on the screen and as the name suggests, assigning their layout on-screen to be cohesive and according to specifications. This also translated to having many components requiring testing, so I assisted in strategizing tests for some of the other files with my teammates so I could be a bit more familiar when designing my tests.

Being a part of this team has been an amazing and enriching learning experience. My group was cohesive and helped each other out when they could, contributing to an enjoyable team environment. Through thorough analysis and collaborative problem-solving sessions, we unearthed and swiftly addressed the root causes of inefficiencies, ensuring a streamlined development process going forward. One of the most significant accomplishments of this sprint was our concerted effort to fortify our codebase with robust frontend tests. Recognizing the importance of software reliability, we dedicated time and resources to meticulously design and implement a suite of tests tailored to our repository’s specific needs. This proactive approach not only bolsters our confidence in the integrity of our code but also enhances our ability to catch and rectify potential issues early in the development cycle. As I look back on the sprint and semester, it’s clear that our team’s collective expertise and collaborative spirit were instrumental in achieving these milestones. By prioritizing quality and teamwork, we’ve not only overcome immediate challenges but also laid a solid groundwork for continued success in future endeavors.

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.

Mastering Automates Testing with Selenium and Java

In the ever evolving world of software development, automated testing has become indispensable. Using tools like Selenium combined with Java, developers can automate their web application testing, improving efficiency and accuracy. This blog post delves into the key takeaways from a helpful Sauce Labs article ( that outlines how to write testes using Selenium and Java, exploring its relevance to our coursework on software testing methodologies

Summary of the Resource:

The Sauce labs article provides a comprehensive guide on writing automates tests using Selenium, a popular tool for web application testing, and Java, one of the most used programming languages. It covers the basics of setting up Selenium with Java, crafting test scripts, running tests, and interpreting the results. The article emphasizes the importance of Selenium for its ability to simulate user interactions with web elements, which is crucial for verifying the functional integrity and performance of web applications. It also touches on integrating these tests into a CI/CD pipeline, demonstrating how automated testing fits into broader software development practices.

Reason for selection:

I selected this article because it offered a practical introduction to an essential skill in software development. As our course covers various testing frameworks and tools, understanding how to implement and utilize these tools in real-world scenarios is crucial. The articles focus on Selenium with Java is particularly relevant, as many of us are familiar with Java and may soon need to apply these skills in internships or jobs.

Personal Reflection.

The article made me appreciate the power and necessity of automates testing in modern web development. It was enlightening to see how Selenium scripts could mimic actual behavior, such as clicking buttons or entering data, which is critical for testing user interfaces. Reflecting on this, I see the immense value in learning automates testing not only to boost my future job prospects but also to ensure that I can contribute to creating robust, user-friendly software.

Application in future practice:

Armed with the knowledge from this article, I am eager to apply these testing techniques in my upcoming projects. Whether it’s for class assignments or eventually in a professional setting, understanding how to set up, write, and deploy automates tests using Selenium and java will significantly enhance the quality of the software I develop and maintain.


Automated testing is a key component of software quality assurance. The insights provided by the Sauce Labs article on using Selenium and Java for testing offer both foundational knowledge and practical steps for anyone looking to enhance their testing skills. As software becomes increasingly more complex, the ability to efficiently test and validate software functionality becomes even more critical, making these skills invaluable for any aspiring software developer.

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Week 15

Last week my group and I were discussing behavior-driven development. It is a type of development that refines our previously learned developments. This is a great jumping point to what we were previously learning and it will make for a great assignment. I would like to give more information on this subject matter because it is valuable. This is another practice that is used in the field that can be used in the future.

Behavior Driven Development (BDD) is an agile testing practice that prioritizes creating automated tests first before specifying system behavior. BDD is utilized in a group setting where both agile teams and business participants can see eye to eye. BDD are tests used to capture a story, feature, or capability from a user’s perspective. During this development, there should be three different heads of mentality to considered. Customer minds usually stakeholders understand the business needs and their desire for new requirements. Developers understand what needs to be done to accomplish their responsibilities and technological feasibility. Test-centric minds should consider any exceptions, new edges, and boundary conditions. There are three phases during BDD discovery, formulation, and automation. The product owner or product manager creates criteria that must be used to write a good story. Then, the discovery process where the team finds any additional information that could enhance the criteria. There is an automation phase that automates the acceptance test. This test shares a lot of similarities with Acceptance Test–Driven Development (ATDD) and Specification by Example (SBE). 

This new development strategy was very useful to learn. It’s good to understand different types of development plans and how you can combine them to make a stronger development cycle. During the agile team cycle, I feel like every cycle you can change what type of software development you use for that cycle. Based on the project, resources, and time you can choose different software developments. Learning about BDD gave me an insight into the business side of the development process. These are things you may not think about when creating your software but should be a priority. You would expect your software project to be examined by someone who is informed in the field but to try to explain to someone that is funding it would be a hassle but necessary. It makes sense that people who aren’t on the team would have to understand the development. It’s a group effort between multiple teams that all must work in unison to create a working product.

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

Week 14

Considering this week we only had one day of class it’s good to reinforce the ideas we learned to spread out in separate classes. I was in a search this week for an article that went into depth about software technical reviews. Software technical reviews are very important; understanding the fundamentals is a key component in the field. 

The main function of a software technical review is to examine a document either in a group or alone and find errors or any defects inside the code. This is done to verify various documents to find if they reach specifications, system design, test plans, and test cases. An important thing to consider is this is a step to make sure the client gets clarity of the project and stays informed on how it’s going. In addition, finalize any changes to reach the requirements before being released to the market. This allows for improved productivity, makes the testing process cost-effective, fewer defects to be found outside the team, and reduces the time it will take to create a technically sound document. The main three types of software reviews include software peer review, software management review, and software audit reviews. The process of software review is simple if you are informed of the implementations taking place. First is the entry evaluation which is just a standard checklist to know the basis for the review. Without a checklist, you will be pulling on strings to find what is wrong with the code or what it’s missing. Then comes Management preparation ensures that your review will have all the required resources like staff, time, and materials. Next is review planning where you create an objective that comes from the team. You then move on to preparation where the reviewers are held responsible for doing their specific task. Lastly, examination and exit evaluation where the group meets up and is discussed to make the team on the same page and verify any discoveries.

Reading this article allowed me to see other steps that are taken to do a software technical review. If we as a team were able to create an objective of what to search for inside the code last week it would have been more goal-oriented instead of randomly searching for faults in the code. As a team, it would have been great to have a more organized group so then when we come together we have an understanding of what we should all find. I would like to see how it would work trying to explain to someone who doesn’t code what has been done and show them that their money is being placed in the right place. Other than that this is a great way to reduce time and be in unison with your team.,an%20object%20in%20the%20software.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

“Draw Your Own Map” Individual Apprenticeship Pattern

This week, I decided to focus on the “Draw Your Own Map” Individual Apprenticeship Pattern for CS448-Software Capstone. This is my final required apprenticeship pattern analysis post, and I chose this pattern because it feels applicable to me as I am about to graduate and enter the working environment, mapping out my intended career path from its starting point. 

The “Draw Your Own Map” individual apprenticeship pattern emphasizes the importance of taking control of one’s career development and learning journey. It encourages individuals to proactively chart their own course rather than relying solely on predefined paths or external guidance.

At its core, this pattern advocates for self-directed learning. It urges individuals to actively seek out opportunities to acquire new skills, knowledge, and experiences that align with their career aspirations. Setting personal goals is essential in this process, providing a roadmap for growth and development.

Identifying various learning opportunities, both formal and informal, is crucial for professional advancement. This could include attending workshops, pursuing certifications, participating in projects, or seeking mentorship. Adaptability and flexibility are also key, as career paths may require adaptation and adjustment over time.

Regular reflection on progress is encouraged to refine goals and adjust course as needed. By reflecting on past experiences and learning outcomes, individuals can iterate and improve their development strategies. Additionally, building a personal brand and reputation within the industry is essential for showcasing skills, expertise, and achievements.

In essence, the “Draw Your Own Map” pattern empowers individuals to navigate their professional journey with autonomy, self-reflection, and continuous learning. By embracing ownership of their career trajectories, individuals can pursue their long-term goals with purpose and resilience.

With such a competitive entry-level environment, it is possible that I may find myself (or at a later point in my career) choosing to take a position that may not fully align with my interests and career goals. Additionally, with all of the ongoing changes in the tech industry and world as a whole, what may have been a traditional and common career path is impractical today. So, it’s crucial that I can draw my own map to success and redraw it as necessary throughout my career. By following the strategies outlined in this apprenticeship pattern, it seems a lot more realistic to be able to take a starting position that may be less-than-ideal while still progressing toward my intended goal.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

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.