Levels of Testing

Levels of testing refers to the different stages of testing software during the development cycle. Each level of testing aims to test specific aspects of the functionality of the software. The most common types of testing levels are unit, integration, system, and acceptance testing. Unit tests focuses on individual components, or units, of the system such as functions. Integration testing is used to ensure that these units work together as intended. System tests verify that the entire system meets the requirements specified by the customer. Acceptance testing is similar to system testing in that the whole system is verified. However while system testing tests the entire system, acceptance testing tests the final system.

Unit Testing

Unit testing is conducted at the code level, where each individual component is tested and the results are analyzed. Rather than manually testing each component, automating unit tests is highly recommended to reduce errors in analyzing and for increased efficiency. When making a unit test, an outline stating the expected results of the code should be made.

An example of an outline for a unit test for a calculator app that simply adds to numbers together would look like:

• Program should accept two numbers
• Program should return the sum of the two given numbers
• Program should handle negative values appropriately

Once the outline for the unit tests are made, then the actual code for the unit test should be written. The test will then check the code to verify it is doing what is expected once the test has run.

Integration Testing

Integration testing tests groups of individual components that are integrated into a system. This type of testing helps to identify any issue that may occur from coding errors or errors from the integration between units.

System Testing

System testing is performed on the application as a whole. All components are assessed against specific requirements made by the customer.

Acceptance Testing

Acceptance testing involves testing the final system. This includes the system’s functional and non-functional aspects such as performance, security, usability, and more. In this testing level, end users are given access to the software to ensure the end users’ needs are being met.

Conclusion

This resource was chosen because it clearly described the different testing levels, their purpose, and why each level is important. I enjoyed reading this article because it was written in a way that made understanding easy. In the future, when creating a complex system, I will be sure to follow the different stages of testing at the appropriate time in the development cycle to prevent issues later in development.

Resources:

https://testsigma.com/blog/levels-of-testing

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.

In my quest to deepen my understanding of effective software development methodologies, I delved into the principles of Test-Driven Development (TDD) through the article “Why Test-Driven Development Works” on InfoQ. This article serves as a comprehensive guide to the fundamentals and benefits of TDD, articulated through the lens of seasoned developers.

Why This Article?

I chose this article because of its practical approach and real-world relevance. InfoQ is known for its high-quality content aimed at software professionals, making it a reliable source for learning about cutting-edge practices like TDD. The article provides a mix of expert opinions and case studies, which helps bridge the gap between theory and practice—a crucial aspect for students and new developers.

Insights and Reflections

The article outlines the core process of TDD which involves writing tests prior to code, ensuring that software development is led by requirements that are continuously tested against. This process is detailed through the cycle commonly known as red-green-refactor:

1. Red: Write a test that fails.
2. Green: Write code that makes the test pass.
3. Refactor: Improve the existing code with confidence.

What resonated with me was the emphasis on how TDD enhances code quality and robustness. By focusing on requirements before implementation, TDD helps prevent future defects and reduces the time spent on debugging and maintenance. Furthermore, the article discusses the psychological benefits of TDD—providing developers with immediate feedback and a sense of accomplishment, which can boost morale and productivity.

Reflecting on these aspects, I recognize the value of TDD not just in preventing bugs but in fostering a disciplined approach to software development. It instills a mindset of accountability and precision, which are invaluable traits for any developer.

Application to Future Practices

Adopting the principles discussed in the article, I plan to incorporate TDD into my academic projects and future professional work. Embracing the red-green-refactor cycle will be crucial, especially in collaborative environments where code quality and consistency are paramount. By practicing TDD, I expect to enhance not only the technical quality of my projects but also the collaborative dynamics within development teams.

Conclusion

The InfoQ article “Why Test-Driven Development Works” is an essential resource for anyone looking to implement TDD effectively. It offers a blend of theoretical underpinnings and practical advice, making it particularly useful for students and new developers. The insights gained from this article will undoubtedly influence my approach to software development, guiding me towards more structured, efficient, and reliable coding practices.

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

I’ve been working on a homework assignment where I’ve been tasked with undergoing the process of test-driven development while working on a code kata where I am to count the number of times each word in a string appears whilst ignoring special characters, spaces and new lines.

To summarize what test-driven development entails quickly, I consulted a blog post by Denis Peganov. Basically, when you do test-driven development, you write tests before you write the code. In practice, this means you have to figure out what the inputs and outputs should be for the code you’re working on, then organize the order with which you should be fulfilling tests in. Denis also mentions the cycle of test-driven development with the red, green and refactor phases. You start with a failing test in the red phase, write the minimum code to make the test pass in the green phase, then, as the name implies, refactor the program to enhance the program’s design if necessary. Denis goes further to make a great point that the iterative nature of test-driven development lends itself to modularity and can create a flow to the evolution of the codebase where this strategy is being applied.

I have to say, doing this in practice is fairly enjoyable up until the point where you have to rewrite everything. The flaw (while it is based upon the practitioner of this strategy of software development) is that if you ‘mess up’ the order of the tests, you can reach a point at which your design needs to change so drastically that you are effectively working backwards. This doesn’t necessarily mean that the strategy is bad, it’s moreso that it does require practice and experience in order to have a smooth development. It also requires the willpower to refactor massive chunks of code when you reach a critical refactor point, which for me it may just be that I’m rusty with regard to coding.

Regardless of this critique, test-driven development does seem to be the best of both worlds. Not only are you able to properly plan software from specifications, but you also get to actively see the results of your code while developing it. It seems incredibly efficient in comparison to other philosophies of software testing, and for me it’s honestly more engaging to write tests and write the code than just writing tests and reading the code that already exists or the specifications alone.

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

A little while ago we learned how Define-Use Testing works as well as how to use it ourselves. However at the time, it still confused me a bit and I wasn’t really sure what it was used for. After reviewing the previous work we’ve done and coming back across this topic, I realized that I still didn’t fully understand what was going on. I decided to look further into it and to do some research in order to understand it more. As a result, I found a website called testsigma which I believe does a really good job at explaining what Define-Use case testing is, its advantages and its disadvantages, and when to use it.

With the website’s help, I’m going to explain everything that you need to know about Define-Use case testing in order to understand it and to know when to use it. As for what a use-case itself is, the website states “The concept of a Use Case can be likened to a real-life scenario in which users and their objectives are present. A Use Case outlines the events unfolding when these users interact with the system to achieve their objectives. The Use Case allows for a thorough understanding of the overall behavior and functionality of the system from the user’s point of view.” Essentially this means that a Use Case shows all of the decisions that were made while the user was trying to achieve their outcome, allowing you to understand all of the behavior and functionality from the user’s perspective. Use Case Testing was designed to make sure that the system that is currently being tested meets all of the expectations. It essentially simulates different real-life scenarios in order to make sure the software does everything that it is supposed to. While the website gives a lot of different advantages and disadvantages of Use Case testing, I’m just going to list a few. Some advantages include helping to identify and validate the functional requirements of a system or software, explaining how the software will be used in real-world scenarios, and helping uncover potential defects. Some disadvantages include it could be time-consuming and require a lot of effort, it may not cover all scenarios which could leave to gaps in test coverage, and it relies on the accuracy of the use case documentation. As for when to use Use Case testing, the website gives a checklist which I found to be extremely useful in my understanding of when to use it. I’m really glad I found this website as it further helped my understanding of the topic, and it has helped me prepare for my final exam. The checklist states:

“1. Review the software requirements, specifications, design documentation, and use case scenarios. 

2. Identify the possible scenarios related to the use case. 

3. Determine the functional requirements of the use case. 

4. Create test cases for each possible use case scenario. 

5. Define the expected results of the use case scenarios. 

6. Execute the test cases and compare them with the expected results. 

7. Retest the fixes after identifying failed test cases. 

8. Check for exceptions and errors for each use case scenario. 

9. Verify compliance and security requirements for each use case scenario. 

10. Monitor the system’s overall functionality across use scenarios. 

11. Validate the overall system performance with user expectations”

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “A Practical Introduction to Test Driven Development” by Luca Piccinelli. I chose this article because it compliments the test driven development topic in the syllabus. This article discusses what test driven development is, the costs of using test driven development versus not using it, and gives some examples of how test driven development is done.

The author of this article is very blunt about their feelings towards test driven development. “These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them. And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST!” As mentioned by the other, some of the advantages that come with using test driven development are you write better software, you have more protection from breaking the whole project when new features are introduced, your software is self documented and you avoid over engineering. However, there is a glaring issue with using test driven development: the cost.

The author discusses the costs of using test driven development versus not using test driven development in good detail. The main differences in the costs are not in terms of value but in timing. “It [test driven development] costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times: you do TDD you have a cost now. You don’t do TDD you will have a cost in the future.” The author feels the best way to reconcile this problem is to do what comes naturally for the project’s development. “The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!” The next section I will be covering discusses how the author feels test driven development should ne implemented.

The author feels that the best way to implement test driven development practices would be to use a top down approach. “[A top down] approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is. For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach”

Article: https://www.freecodecamp.org/news/practical-tdd-test-driven-development-84a32044ed0b/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Starting the Docker service also starts the Docker Daemon. However, if you receive the “Cannot connect to the Docker daemon” error, the daemon may have failed to initiate.

Use the following command to run the daemon manually:

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

Take 2

Well here we are, back again talking about clean code. I thought it would only be fair to introduce you to its evil counter part. Now that I really think about it, I really must be goo at these blogs because I am giving away the secret recipe to the perfect code. If you know how to write clean code BUT also know how to avoid bad patterns thats the ulntimate duo, nothing should stop you!

What is Anti-Pattern

it is how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design practices, and they are typically ineffective or obscure fixes. They can lead to issues such as technical debt, where suboptimal code must be addressed and corrected later.

1. Spaghetti Code:
   • Description: Code with little to no structure, making it difficult to follow.
   • Issues: Maintenance nightmare, challenging to add new functionality, and prone to breaking existing code.
2. Golden Hammer:
   • Description: Overreliance on a specific architectural pattern or tool.
   • Issues: May lead to performance issues, difficulty adapting to different problems or languages, and inhibits learning and exploration.
3. Boat Anchor:
   • Description: Leaving unnecessary or obsolete code in the codebase with the assumption that it might be needed later.
   • Issues: Causes confusion for developers, longer build times, and the risk of inadvertently activating obsolete code in production.

Why we might use it still

1. Prototyping or Rapid Development:

• In the early stages of prototyping or rapid development, the primary focus might be on quickly testing ideas or demonstrating concepts. In such cases, developers might use shortcuts that resemble anti-patterns to expedite the process. However, it’s crucial to revisit and refactor the code for production use.

Anti-pattern is a practice or solution that may seem like a good idea at first but, in reality, is counterproductive and can result in negative consequences for the software development process. It’s a term used to caution against common pitfalls and encourage developers to adopt best practices for creating maintainable, efficient, and effective code.

While there may be rare instances where the use of anti-patterns is justified, such as in prototyping, rapid development, or within legacy systems, it’s essential to recognize that intentional use of anti-patterns comes with inherent risks. These include technical debt, reduced code quality, and challenges in maintaining and scaling the software. I still encourage developers to prioritize clean code above all else.

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

Not too long ago, I learned about the “Agile” methodology for the first time. I learned all about how following “Agile” allows for code that is always functional and that can be built off of in a much more proactive way than that of code produced through the waterfall approach. What I did not learn as much about, however, is the impact that following an agile methodology has on the customers, the vendors, and the project manners, as many of the lessons I took part in were developer-focused.  

In order to learn more about the impact of the Agile methodology project members, other than developers, I did some research and came across a blog post titled: “8 Benefits of the Agile Methodology” by Erin Aldridge. This blog post takes the approach of describing the benefits of using an agile process through the perspectives of people who would otherwise not be working directly with the code. 

CUSTOMER BENEFITS:

The article identifies the way in which incremental delivery of a project often results in higher levels of customer satisfaction, as well as provides greater customer involvement and input on what they are looking to receive as a final product. This higher level of customer satisfaction is also paired with a higher return on investment for the customer.

VENDOR BENEFITS:

From the perspective of a vendor, it becomes much easier to ensure a high-quality product, or a product that satisfies the customer when a new increment of the product is available at the end of each sprint. Increased level of transparency on the progress being made on any given project also allows for a vendor to more effectively work with a small-sized team and communicate in meaningful ways with the customer. 

PROJECT MANAGER:

While working with “Agile”, developers are able to get right to working on a project, cutting out much of the uncertainty that may be created as a project manager attempts to figure out all the parameters for the project. Project managers are also able to better select tasks to be prioritized first, and will find it much easier to keep track of project progress through the points emphasized during each daily scrum meeting. 

From what I have discovered, using “Agile” seems to be better for every member of the development process compared to other methods like the “Waterfall” process. I have also learned through this research that implementation of the agile methodology is more simple than often thought and improves nearly every aspect of the work process (as mentioned through points above). To add to this, I also now have a better understanding of the role everyone plays as described by someone who actively uses “Agile” in a real workspace. In fact, I now believe that the agile process is easy enough to implement that I will very likely recommend its use in future projects that I take part in. 

Blog Referenced: 8 Benefits of the Agile Methodology – Project Management Academy Resources

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

In many of the previous classes that I have taken throughout my college process, I have been tasked with writing code. However, in nearly all of the assignments I have received so far, instructions only require the code to be working or at most want there to be comments to go along with said code. After reflecting on this fact, I began to think more about how there must be some sort of standards for writing code; some sort of quality control when it came to preparing code for use in a professional environment. This is where the practices of writing “clean code” come in.

Recently, I have read a blog post called: “Writing clean code: best practices and tips for developers” by René Cadenas, in which the author went on to outline several key points to follow when improving the readability and cleanliness of code. I chose to read this article in order to develop a better understanding of the topic covered in class, as well as to create a better understanding of how I can implement the use of clean code practices in future workspaces.  “Clean code” is defined here as “code that is not only functional but also easy to read, understand, and maintain”. The author also wrote about why clean code matters, claiming that it leads to improved collaboration between developers, and that implementing defining features of clean code, like meaningful naming conventions, proper documentation, and reusable code blocks that don’t require other developers to repeat efforts and redundancy, will all lead to a final product that follows the principles of writing “clean code”. Other topics of emphasis in the blog post were: consistency of code, clarity of comments, and efficiency of the code written.

After having read this blog, and through our classes in which we had our own lessons of writing clean code, I now understand why it is such an important aspect of writing code. After reading the article, I learned about how much of a difference refactoring code can actually make when it comes to the readability of code, which I didn’t consider throughout our in class discussions. After seeing examples of refactored code alongside the same code in its non-refactored form, it really convinced me to try harder to implement these practices in my own writing of code. Moving forward from this point, I want to put a lot more thought into how I write my code and whether other people are clearly able to understand it in the same way that I view it. After all that I’ve seen on the topic, I think the best way to go about this is through practicing more on implementing these “clean code” practices in my own work. I think it might even be a good idea to use a separate “clean code” guide to double check code I write in the future before submitting it. 

Blog Referenced: https://blog.elaniin.com/writing-clean-code-tips-for-developers/ 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.