Category Archives: CS-443

Embracing Test-Driven Development for Quality Software (Week-13)

In the evolving world of software development, methodologies that enhance code quality and project efficiency are highly prized. Test-Driven Development (TDD) stands out as a pivotal methodology, advocating for tests to be written before the actual code. This approach is detailed compellingly in the Semaphore article “Test-Driven Development: A Time-Tested Recipe for Quality Software,” offering valuable insights into the TDD process and its benefits for developers and projects alike.

TDD is anchored in a cyclic process known as “red-green-refactor.” Initially, a developer writes a test for a new function, which fails (red stage) because the function isn’t implemented yet. Then, minimal code is written to pass the test (green stage), focusing on functionality before perfection. The final step involves refining the code without altering its behavior (refactor stage), enhancing its structure, readability, and performance.

The significance of TDD in software development cannot be overstated. It promotes incremental development, allowing for manageable progression and easier troubleshooting. The necessity to write tests first compels developers to deliberate on code design and interface upfront, leading to cleaner, more maintainable code. Additionally, TDD provides a safety net, enabling developers to modify or add new features with the confidence that existing functionality remains intact, as verified by the tests.

Despite its advantages, TDD is sometimes viewed skeptically, with critics pointing to its perceived complexity and the upfront time investment in test writing. However, the Semaphore article counters these arguments by highlighting the long-term benefits: reduced debugging and maintenance time, deeper codebase understanding, and ultimately, a more streamlined development process. The initial efforts pay off by preventing future headaches, underscoring TDD’s efficacy in building robust, high-quality software.

TDD marks a paradigm shift in software development philosophy. It prioritizes a meticulous, forward-thinking approach to code creation, where quality, efficiency, and thoughtful design are paramount. The practice of writing tests before code not only ensures functionality but also fosters an environment of continuous improvement and refinement.

The Semaphore article serves as a robust endorsement of TDD, encouraging developers to adopt this methodology for its substantial benefits. TDD is more than a set of procedures; it’s a mindset that values thorough preparation and continuous enhancement. For those seeking to elevate their development practices, embracing TDD could be the transformative step needed, leading to projects that are not just successful but also sustainable and adaptable in the long run.

Delving into Test-Driven Development can significantly impact the quality and sustainability of software projects. For those interested in a deeper exploration of TDD, the Semaphore article provides an excellent starting point with comprehensive insights and practical examples.

Read the full Semaphore article on Test-Driven Development here for an in-depth understanding of how TDD can transform your software development process.

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

Writing Testable Code

For this week’s blog I decided to dive a bit deeper into writing testable code because I think it is a valuable skill. While searching for blogs that discuss this topic I found “TDD: Writing Testable Code” by Eric Elliott. In this blog, Elliott explains the importance of writing testable code barriers to writing testable code, and different tips to keep in mind to write testable code. 

The first thing he touches on is how a good quality process is essential to continuous delivery. One of the most important principles, he mentions, is the separation of concerns because “simplifies complexity and enhances the overall quality of your work”.

In the overview about testable code, he explains that achieving testable “allows for more efficient and effective identification of defects, ensuring higher quality and reliability”. The key characteristics of testable code are modularity (when code is organized into discrete units), clarity (code that is easily comprehensible), and independence (when code can be tested in isolation).One of the barriers of writing testable code that Elliott describes is tight coupling in code. The coupling in code is the instance where changing one part of the code can heavily impact or even break the functionality of another part in the code. If one part is changed there can be a chain reaction of bugs in various other parts of the code. Right coupling can be caused by parent class dependencies, shared mutable states, concrete class dependencies, event chains, state shape dependencies, control dependencies or temporal coupling. He explains that to write testable code you must reduce the forms of tight coupling mentioned because it makes testing easier and promotes a “more sustainable and scalable codebase”. This is why testable code and maintainable code are the same thing. 

Later he explains the test first vs test after approaches. The test first approach is the test driven development approach where tests are written before the code. The benefits include better developer experience and clearer requirements and design. The test after approach is where the tests are written after the implementation which leads to a probability of biased tests and reduced code coverage.

One of the last sections provided is about the separation of concerns which a  design principle for programs into distinct sections that  addresses separate concerns”. This principle is important because it allows independent testing and allows developers to isolate problems more effectively in addition to allowing the ability to make changes without unintended consequences. He describes that he likes to isolate into 3 distinct sections business and state logic (the core logic of the application), user interface, and I/O and effects (the part of the application that interacts with the database).

I think this source was well organized and easy to follow. It made the text easy to understand and provided great advice for writing testable code. I think the last section about how he likes to isolate the sections was especially helpful and I will keep it in mind for the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website: https://www.code-intelligence.com/blog/11-tips-unit-testing-java

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

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

A Software QA Student’s Guide to Impactful Code Documentation

Hey everyone! I found the article “Elevating Your Test Automation Projects With Meaningful Code Documentation” to be a valuable resource that directly relates to the course material. The article begins by highlighting the common challenges faced when trying to understand existing automated test code, such as unclear naming conventions and a lack of explanatory comments or documentation. Dickson emphasizes the importance of documenting code to ensure that both new and experienced team members can easily comprehend the purpose and functionality of the automated tests.
One of the key points discussed in the article is the effective use of comments. Dickson outlines two simple rules for writing meaningful comments: avoiding redundancy and being informative and concise. She provides an example of a Cypress test where the description of the test case made the additional comments unnecessary, as the test was already self-explanatory. On the other hand, Dickson suggests adding comments to explain the purpose and implementation of more complex code.
Another valuable documentation technique covered in the article is the use of docstrings. Dickson explains how docstrings, which are associated with specific code blocks, can greatly improve the reusability of the code. She demonstrates the power of docstrings by showing how they can provide information about function parameters, return values, and usage examples, making it easier for collaborators to understand and effectively utilize the code.
Dickson outlines several popular naming conventions and explains the benefits of using descriptive and consistent names for variables, functions, classes, and files. She highlights how these naming conventions can enhance the readability and organization of the codebase, ultimately making it more maintainable and collaborative.
As a software quality assurance student, I found this article to be particularly relevant and helpful. The author’s clear explanations and examples have assisted my understanding of the role that code documentation plays in the success of test automation projects. I can already can imagine applying these practices in my own future work, where I will continue to create well-documented and easily understandable test automation code.
Furthermore, the article’s emphasis on collaboration and code reusability stays with me, as I recognize the importance of working effectively with cross-functional teams in the software development process. By prioritizing meaningful code documentation, I can make sure that my fellow team members can understand and build upon the automated tests I create.
In conclusion, “Elevating Your Test Automation Projects With Meaningful Code Documentation” is a vital resource that has pushed my thinking for the role of code documentation in software quality assurance. The author’s practical advice has provided me with the knowledge and tools to enhance the readability, maintainability, and collaboration within my own test automation projects. I am confident that applying these principles will lead to more efficient and effective test automation, ultimately contributing to the overall quality and success of the software I help develop.

April 7, 2024
andicuni
https://www.ministryoftesting.com/articles/elevating-your-test-automation-projects-with-meaningful-code-documentation

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Workstations: The best setup for CS Students

Here’s the thing, having the right workstation isn’t just about keeping up with the cool kids anymore, it’s about finding the right blend of power, ergonomics, and style to run through coding marathons, debug sessions, and endless project nights. Let me guide you through what, in my opinion, is the best (somewhat cheap?) setup you could have as a CS student.

First off, the centerpiece of your digital dominion: the Laptop. You know that for CS students the laptop is not just some tool you use, it’s your best friend, your main weapon, your Excalibur and as such It needs to be powerful enough to compile the code faster than you can say “runtime error”. Try to find a laptop that has:

  • Powerful CPU: Intel Core i7 or i9, or AMD Ryzen 7 or 9. If you’re into Macs, Apple’s Silicon chips have proven their efficiency these past years so if you can afford it, go for it.
  • Plenty of RAM: 16GB should be your starting point. If you’re into machine learning or running multiple Virtual Machines, 32GB should be your sweet spot.
  • SSD Storage: Waiting for your IDE to load is so, 2010’s. Most laptops now come with 256GB SSD, if you juggle multiple projects you can upgrade to 1TB.
  • Graphics Card: Look into a graphics card that is affordable but also new, It will be useful not only for GPU programming and A.I. work but also for winding down by running some of your favorite AAA studio games.

Some people might be content with only a laptop as their workstation and I can’t say they are wrong as some of you living in dorms might not have the space for your workstation, but trust me when I say that setting up peripherals is a game changer.

  • Hi-Res Monitors: A single 27-inch, 4K monitor can drastically change your coding experience by reducing eye strain and improving readability. It works great for having your code on one screen and your reference material on your laptop. I’m running a 34-inch ultra-wide + 15.6-inch laptop on the side. Maximum real estate.
  • Mechanical Keyboard: Once you go clack, you never go back. The tactile feedback is not only satisfying but also reduces typing fatigue. Plus, it makes you feel like a hacker from a 90s movie.
  • Ergonomic Mouse: Your wrist will thank you if you get a mouse that is fit for your hand, try to find something that feels right for you.
  • Quality Headphones with Noise Cancellation: For when you need to zone out and focus, or just vibe to some tunes while debugging.

Don’t be afraid to express yourselves whether it’s with LED lights, action figures, or posters of your favorite GitHub repos, make it yours. You’ll be spending a lot of time here, so make sure it’s a place that inspires you.

By now you should have what is essentially a perfect workstation. You have your laptop around campus, your station to hook it up and unleash its potential.

This is my personal working space,I hope it inspires you. Till next time,

Ano out.

References

https://www.techradar.com/pro/best-laptops-for-computer-science-students

https://simpleprogrammer.com/best-laptops-for-computer-science-students/

https://medium.com/technonerds/desk-setup-2020-peek-into-the-gear-i-use-daily-as-a-student-f88ea8be16f5

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Understanding Integration Testing and System Testing.

When it comes to software development, ensuring that the final product meets the desired standards is crucial. This is where testing comes into play, and two significant types of testing are Integration Testing and System Testing. Let’s delve into what these testing methods entail and how they contribute to the quality of software products.

Integration Testing

Integration Testing focuses on testing the integration or interaction between different components or modules of a software system. In simpler terms, it examines how well individual units work together as a whole. This testing phase occurs after unit testing, where individual units of code are tested in isolation.

During Integration Testing, developers verify the interfaces between the units to ensure that they communicate correctly and exchange data appropriately. The main goal is to detect any defects or inconsistencies that arise when integrating these units. Integration Testing helps in identifying issues such as communication failures, data corruption, or incompatible interfaces early in the development process.

There are several approaches to Integration Testing, including top-down integration, bottom-up integration, and incremental integration. Each approach has its advantages and is chosen based on the software architecture and project requirements.

For more in-depth information on Integration Testing, you can refer to this link.

System Testing

System Testing takes a broader perspective by testing the entire software system as a whole. Unlike Integration Testing, which focuses on unit interactions, System Testing evaluates the system’s behavior and performance concerning the specified requirements.

In System Testing, testers validate various aspects of the software, including functionality, usability, reliability, and performance. This phase involves executing the software in an environment that closely resembles the production environment to simulate real-world usage scenarios. The goal is to ensure that the software meets the stakeholders’ expectations and functions correctly in different scenarios.

System Testing encompasses different types of testing, such as functional testing, usability testing, performance testing, and security testing. Each type of testing addresses specific aspects of the software to ensure its overall quality and reliability.

To learn more about System Testing and its types, you can visit this link.

In conclusion, Integration Testing and System Testing are integral parts of the software development lifecycle that help ensure the quality and reliability of the final product. While Integration Testing focuses on the interaction between individual units, System Testing evaluates the system as a whole. By conducting thorough testing at each stage of development, developers can identify and address issues early, leading to a more robust and reliable software product.

By understanding the concepts of Integration Testing and System Testing, developers and testers can effectively ensure the quality and reliability of their software products, ultimately enhancing user satisfaction and trust.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Decision Table Testing

The blog post, “Decision Table Testing: Everything You Need to Know”, discusses the concept of decision table testing in the software quality assurance field. Decision table testing is a systematic technique used to test the behavior of software systems against various input conditions. The blog post provided a comprehensive overview of decision tables, their components, advantages, and how they can be effectively utilized in software testing processes. In addition, the blog post offered practical insights into creating decision tables and implementing them effectively in test creation. It discussed the best practices for defining conditions, actions, and rules within decision tables, emphasizing the importance of clarity and consistency. Additionally, it provided tips for managing decision tables in a structured manner, facilitating easier maintenance and updates as the software evolves.

I chose this blog post because we have covered this topic extensively as well as incorporating a homework assignment on the topic. Due to this, I wanted to have further instruction on how this method of testing can be put to use and gain further knowledge on the method of testing. After reading the blog, I was able to gain a clearer understanding of decision table testing and its significance within software testing. Decision table testing is a very important testing method that will be a very useful tool to know and understand in use when testing for software quality assurance.

The blog highlighted the benefits of decision table testing, such as its ability to identify redundant test cases and minimize duplication efforts which are great to learn as it will help increase functionality of my tests as well as efficiency. From the blog post I was able to gain a greater understanding of Decision table testing and with that deeper understanding of decision table testing, I hope to be able to have real world scenarios that I would be able to apply the theory to. In conclusion, the resource not only expanded my knowledge of decision table testing but also equipped me with practical insights that I hope to be able to apply in my academic as well as my professional career in the future. As I continue to write and develop code for class and hopefully for career opportunities the more knowledge I have when it comes to software testing the better as it will help improve my level of design. Understanding one of the fundamental testing methods is just a step in the right direction for my career.

https://testsigma.com/blog/decision-table-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.

Unit Testing

The blog written by Krishna Teja Dinavahi, “Unit Testing – Is it Really Helpful?” (https://engineering.zoominfo.com/unit-testing-is-it-really-helpful) does a great job explaining the importance of writing unit testable code. What is also mentioned is how unit testing and integration testing are two different forms of testing that are both equally important. I specifically enjoyed this blog because of the great examples of code that was not unit testable along with the steps taken to refactor the code. 

What is Unit Testing and How is it Helpful?

As it’s mentioned in the blog, looking up unit testing online will give you the textbook definition, “Unit tests help you test individual parts of your application in isolation.” This is the same thing that was described to me in class, but I had the same general reaction to unit testing as Dinavahi describes. Unit testing can sometimes feel tedious and redundant. However, the real importance of unit testing is clear when you explore code that is not unit testable. Unit testing can not be done on code that is written poorly. This was the biggest eye opener for me as I read this blog, especially with the great examples provided. Notably, the one where having the external dependencies in its own function allows for easy bug fixing if anything was to change in the eternal API.

What Makes Code Unit Testable?

As I recently began refactoring old code with some of the new techniques and agile methods, I noticed the largest hurdle for me is being able to create “pure functions.” These are functions that are limited to doing one task and are very clear what that task is. From my experiences, having pure functions and good naming conventions are the two most important aspects to readable and scalable code. Approaching the code with unit testing in mind, the should automatically be written in a way that you will create pure functions. 

Conclusion

As someone who strives to write clean, readable code, I feel like I share the motivation Dinavahi expresses in the blog when it comes to learning unit testing. Each time I have refactored my code, I have always felt like it was just not finished. However, using unit testing I will be able to identify which parts of my code are not written properly and need to be refactored again. This time, with the knowledge of the steps I can take to get to unit testable code. 

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

Knowing Test-Driven Development (TDD)

Hello everyone,

Today I want to talk about test-driven development (TDD), which plays an important role in software development and testing, and improves the reliability and quality of software products. Through my recent exploration of software testing knowledge, I learned the importance of TDD. So I recommend this blog. This blog provides an in-depth discussion of understanding TDD, its impact on software development, and how I foresee integrating this approach into my future practice.

Link: https://semaphoreci.com/blog/test-driven-development

By Ferdinando Santacroce

This blog explains the three-step cycle of TDD (write tests that fail, write minimal code to pass the test, and refactor) and the benefits associated with this approach. It illustrates how TDD promotes improved code quality, faster development cycles, and better software design, all of which resonate with what I learned in the course.

My personal code writing habit is to write the functional part first, and then write the corresponding test function to test its completeness. But TDD gave me a new choice, which is to write the test part first and then write the functional part. This gave me new inspiration. Maybe the TDD model will be more conducive to our work.

The author also wrote several interesting examples to help us understand how TDD works. He also reiterated that “TDD is a code technique, not a testing technique.” My personal understanding is that TDD can not only be used in the field of testing, but also can be used to think about any code-related issues, not just Just used for testing functionality.

Overall, TDD is not just about testing. it is also a mindset that prioritizes testing and quality from the outset of the development process. By adopting TDD, developers can build software with greater confidence, knowing that it has been thoroughly tested and meets the specified requirements.

From the blog CS@Worcester – Ty-Blog by Tianyuan Wang and used with permission of the author. All other rights reserved by the author.

Week 12

Considering that we have been working on the Mars rover for the past two weeks, I decided to find an article that correlated with this. I went straight to the source and found something about the actual Mars rover. I was able to find an article that piqued my interest. This article was specifically about the real rover and the people who worked on it. I chose this article to show the broad potential we all have inside the CS field that none of us even heard about. I hope to open your minds to all the possibilities you can do with code.

    The article begins by introducing the reader to Melody Ho a full-stack developer for the Nasa Mars website. She has a multitude of responsibilities she has to publish information about every mission and create data pipelines to be accessible to the public. Her journey began by working on a basic HTML book and playing computer games. She gives her reflection on her journey to inspire the next generation of women in space and technology. She most enjoys programming code that is efficient and adapting it to the best version of code possible. When she was growing up she was considering a career in computer games because she hadn’t yet seen the opportunities available for programming. She leaves the article by advising the next generation. She says to embrace new things and don’t be scared because these are opportunities that are needed to succeed. Technology is constantly changing don’t be discouraged if all doesn’t click it will take time.

   Reading this article gave me more of an introspective view of someone’s life in coding. This article doesn’t have much connection to the code we do in class but I think it’s very interesting to see the whole perspective of a coding journey. This article touches upon aspects that you may not think about every day but it gives much attention to what is important. Melody trying to inspire the next generation is very touching. She didn’t have to do this but she did. For me, it gave me a broader view of programming because sometimes you may have a tunnel vision of what you can do with your code but the possibilities are endless. There are a lot of connections that you may not see on an everyday basis. She mentioned how she double majored in business and I didn’t even see the correlation of coding in a management setting but it’s there. There are a lot of connections in programming with other skills there are some I haven’t thought about.

https://airandspace.si.edu/stories/editorial/coding-brings-mars-data-down-earth

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