Hello everyone,

This week’s blog topic is about Static Testing vs. Dynamic Testing. This is something we discussed at the beginning of the semester but nonetheless is still very important to know. It took me a bit of time to understand the differences between the two and when was each one used but after reading this blog it made it a lot clearer to understand but let’s start with what they are. Let’s start with just a simple definition to separate the two terms. Static Testing which is done manually without executing the application and dynamic testing is an automated approach that involves executing the code and testing it in various ways within a closed run-time environment. If we read more into the blog we can understand that Static Testing is the process of checking an application or website without executing the code. It’s a manual process and it is done usually in the early stages of the development life cycle. A person compares the code against the requirements and specification  that he needs to meet and this review allows him to identify any flaws, defects or possible changes. Now Dynamic Testing is more for the customer and user experience and it is the process of executing controlled tests and experiments on live digital platforms with real user traffic. Unlike static testing, where you manually have to review the design and the actual code, dynamic testing deploys different variations in order to understand how users behave and then they can analyze user engagement and other performance data.

The blog does a great job of not only explaining the definition of the two different types of testing but also gives the Advantages and Disadvantages for both. For example as per the authors notes he says that Static shines on identifying  potential experience issues upfront in the early stages of the development process. This helps to positively impact performance metrics before launching to the customers and also prevents a poor experience for the developers as well. But it has some disadvantages like it heavily relies on the expertise of reviewers evaluating designs, the better the reviewer the better the static testing. It is also very time consuming and may not catch flaws that can only appear in real and actual user interaction. For the Advantages of Dynamic Testing we have that it is amazing at allowing continuous optimization of multiple experiences. It has Controlled experiments that lets you roll out new features and experiences with minimal risk and its ability of Automated testing means you can quickly scale testing. While it sounds amazing and all it has some Disadvantages which are that it can be very time-consuming for complex experiments with many versions. In some cases it won’t cover every potential user scenario and edge case and it requires a lot of upfront investment in testing tools. 

In conclusion, it is very important to know and use both testing types so you can get the best of both worlds!

Source:

https://monetate.com/resources/blog/static-testing-vs-dynamic-testing/

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Summary of the Blog

The article emphasizes that code reviews are not just about finding mistakes but are primarily about improving code quality, spreading knowledge across the team, and building better, more maintainable software.

• Code reviews help maintain consistent coding standards across a project.
• They foster team learning, as developers can see different approaches to solving problems.
• Good code reviews catch potential bugs and architectural flaws early, preventing costly fixes later.
• Reviews create a sense of shared ownership over the codebase, leading to more sustainable, long-term development.

He also stresses that code reviews should be approached positively, focusing on collaboration rather than criticism. The goal is to help, not to criticize harshly, and reviewers should offer suggestions rather than simply pointing out what’s wrong.

Why I Chose This Resource

I chose this blog because it reads as someone who actually has been through the experience of not doing them and realizing the hard way why they exist and are used regularly. It’s a resource that goes through the whole process of code reviews, but the added element of feeling that the person writing it actually understands why the thing they are explaining is useful makes it feel a lot more credible. It also just makes it easier and more interesting to read in my opinion.

Personal Reflection

Messy codebases can lead to immense technical debt over time, and code reviews are the solution. Of course it would be great to simply adhere to the rules and standards set by the group to avoid the sloppiness in the first place, but the code reviews are necessary to ensure that if there is messy code it doesn’t make it into the production branch, like a last defense. The steps laid out in the blog create a healthy environment to improve the code being reviewed, while also being respectful in the manner it is done. The checklist of standards to go over during the review makes sense and is the base of keeping everything “correct”, but it pleasantly surprised me when they mentioned the correct way to communicate the changes. Most people wouldn’t think about how they mention the changes found, but this blog states the correct way, even showing examples, which takes into account respect for the developer as well as being descriptive / informative with the comment. 

Conclusion

This blog made me understand why code reviews are important. Before reading I thought similarly to the author that code reviews are a waste of time and just some bureaucratic process, but now I see that the time spent on making all of the code cohesive and adhere to coding standards actually saves a lot of time in the long run from fixing bugs and reading sloppy code. 

Citation

Kravcenko, V. (n.d.). The Importance of Code Reviews. Retrieved from https://vadimkravcenko.com/shorts/code-reviews/

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

For this weeks’ log entry, I wanted to cover a topic that was a bit different from the post that I made last week. One topic that caught my eye as being a perfect option to learn more about was Behavior Driven, and potentially also Test-Driven, development of code. When researching this topic, I came across a podcast titled, “Behavior-Driven vs Test-Driven Development & Using Regex in Python” by The Real Python Podcast on spotify. One of the largest factors that drew me to choosing this podcast to learn from was the fact that it was made incredibly recently (only a few months ago).

TEST-DRIVEN DEVELOPMENT:

A process of developing code that revolves around writing automated tests for code before ever actually writing the code itself. The process starts with a programmer writing a test for some sort of new feature that they want added to their code or that they want their code to be able to solve. After this, they write the smallest amount of code that they possibly can in order for that test to pass, potentially refactoring after the test is passed if they feel a need to do so. TDD originated before and was used to heavily inspire the agile process and scrum methodology that we see used today. TDD can be a helpful process to follow for several reasons. First, it ensures that you have actually written good tests and helps to mitigate any sort of temptation to cut corners when working on a project. TDD also helps teams to work specifically within the realm of what is being asked of them, rather than “gold-plating” their work and adding other features to their code that may not have been asked of them. Overall, TDD is very structured and easily provides a path for workflow to follow without confusion.  

BEHAVIOR-DRIVEN DEVELOPMENT:

BDD for short, in a way it is an extension of TDD, only focusing on the highest levels of the testing pyramid and involves Acceptance Test Driven Development. Essentially, before you ever write the function that you would use to test in TDD, you first write tests about how you think the application is actually supposed to behave. It focuses on a feature behaving in a particular way as opposed to that same feature returning a particular response. First, you would identify things that your code would need to create some sort of list that can be used to define what needs to be done or whether or not that feature is properly working. After identifying the need, you would write high level tests to check this. Same as in TDD, you would essentially be writing the code in parts, running tests in between to ensure that the code being written is being done so with an immediate purpose and goal to achieve within the project.

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

For this blog post, I’d like to discuss an interesting piece by Jeremy D. Miller titled “Effective Test-Driven Development”. It provides some practical tips and advice for developers on how to make the most of Test-Driven Development (TDD). I found it very relatable because it relates to what we’ve been discussing in our software development class, particularly testing and keeping our code in good shape.

Miller’s article delves into TDD, which entails writing tests before coding. While TDD is a common method, he explains how to avoid common issues and adhere to best practices. He discusses how too much setup code, slow feedback, and unnecessary tests can all contribute to slow performance. He contrasts these issues with good habits such as writing quick tests, providing timely feedback, and ensuring tests are clear about what they check in the code.

Miller also discusses how TDD can help with design and quick feedback. He mentions that TDD encourages developers to plan out how their code will look, making it easier to maintain and less buggy. The goal is to make testing an integral part of development rather than a final step, so that problems can be identified early.

I chose this blog because we had only touched on TDD in class and I wanted to see how it applied in real-world software development. I thought it was fascinating that TDD is about more than just writing tests; it’s also about improving code structure. Miller’s suggestions are ones I’d heard of but hadn’t looked into thoroughly. His advice helped me understand how TDD can improve code quality and make life easier for developers, which is extremely useful to me as a student learning to write solid code. Reading this blog made me realize how important it is to write tests that do more than just check if things work; they should also ensure that the code is easy to change later. Miller, for example, discusses “happy paths” in which tests check for expected results and “negative tests” in which errors are handled. This is consistent with what we’ve been learning about testing, but it also gives me a better understanding of how TDD can help clean up and improve code over time.

Miller’s post emphasizes the importance of not rushing through TDD. It’s better to take your time and write clean, manageable code. I found this extremely useful because, as a beginner, I frequently feel the need to complete tests quickly. But Miller reassured me that taking it slowly can save time in the long run by identifying problems early on.

I intend to use TDD more actively in future projects. By writing tests first, I can keep the end goal in mind from the start, reducing the need for major rewrites later. I also feel more confident about refactoring because TDD will help me keep the code solid while I make changes.

In the future, I want to incorporate Miller’s concept of clear intent expression into my code. Writing tests that clearly demonstrate what the code is supposed to do will simplify things for others and help me stay focused when working on larger projects.

Blog: https://jeremydmiller.com/2022/10/03/effective-test-driven-development/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

While teamwork may not be listed as one of our topics for the course, if I’ve learned anything during this semester it’s that teamwork yields massively more results than testing alone. We just recently did an assignment where we were given “shaky” code to look at and record any errors we found. We started by going off on our own to look for errors. We then came back together to see what everyone found, and it was amazing how different our lists look. Even though it was the same code everyone caught a ton of different mistakes.

There are plenty of benefits to teamwork in the software testing field. “The Importance of Collaboration in Software Testing Teams” is a great blog I discovered that fully goes over these benefits. Unfortunately, the author did not leave their name anywhere and signs off as “admin” so I can’t give them the full credit due, but I linked the blog above if you want to give it a read over.

Some key takeaways are early issue identification, improved software quality, and increased efficiency. There’s many more listed in the blog, but these are the three I find most important.

In one of my previous blogs, I mentioned just how much more it can cost to fix a mistake that slips through the early phases of software development so having early issue identification is huge. Through multiple eyes looking at the same software everyone is able to use their own unique perspective to weed out as many bugs as possible.

As for improved software quality and efficiency, how can you not say yes to better software, faster. That’s just a win for everyone. Every developer has their own style and methods to solving problems and by combining them you can create innovative solutions that can drastically increase efficiency while creating more sound programs.

Teamwork has been a large part of my computer science degree at Worcester State. I plan on continuing to sharpen my skills as both an individual and a teammate as I progress through my career both academically and professionally.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

TDD or test driven development is a method of building software by creating tests first and then writing the implementation of the code. This blog breaks down what TDD is and the steps to the process. TDD aims to help developers build a program that meets the requirements. By building to meet certain criteria, programmers will always keep the goal in mind. Building with certain behaviors or outputs in mind. The first step is to write a test list. Essentially you are writing tests with the end behavior in mind. It is writing tests, but this stage is also an analysis. An analysis of what the programmer or team or whoever thinks the final program behavior looks like. The next step is to write a test, one that is robust and fully implemented. With one test implemented, the program implementation is now taking shape. Because the program must be made in a way so that it will work for the test. Now that you have a test, the next goal is to make that test pass, by any means necessary. After that you can refactor depending if the tests or implementation needs to be changed to make the program better. Then it becomes a matter of repeating the process until the test list is through.

I think TDD is a very interesting approach to programming. Usually we think of the typical process of build first and then testing. But TDD reverses that, and it creates a very dynamic when it comes to building software. I never really thought about it before but the way you build a test does affect the way the program is implemented. Like if your test is expecting a string or integers, you have to build the implementation in a way that returns those types. There are many ways to make a test that does the same thing. But those tests go about it in a different way. Thus that changes the way you program the implementation. I also think TDD adds focus and direction to programming. As you always know what you need to return or what the expected output looks like.

https://tidyfirst.substack.com/p/canon-tdd

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Black box testing is one of many testing paradigms in the world of testing. I think black box testing stuck out to me because it has the coolest sounding name. This blog is an overview of what black box testing is, when and where to use it, and the pros and cons. The main idea around black box testing is to test a program without knowing the inner workings of the program. Essentially you give the inputs to the program and receive the outputs. But you don’t know what’s going on in the in-between. Black box testing can also be split into even smaller forms that each serve a different purpose. For example, there is functional testing that aims to assess the program’s ability to return outputs that match the specifications. Another example would be system testing, which aims to test the program as part of a larger system. Testing to make sure that the entirety of the program works. Some of the pros of black box testing is that it simplifies testing because it focuses on user requirements. Cutting out on other factors to make sure that the user experience is good. Cons include limited test cases because of limited knowledge of the program. Tests are often simple due to the nature of the lack of information.

I think black box testing is an important part of testing because it’s testing based on the perspective of the users. Most users of an application don’t know the inner workings of said application. So making sure that everything is working on the user side ensures that the user experience is quality. After all, if the people using the application hate it, then they want to use it. And they probably dont want you to work for them again.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Blog Post: Making Code Stronger with JUnit 5

This week, I found a blog post called “Increasing Code Fortification: A Guide to Security Testing in JUnit 5”, and it gave me a new way of thinking about security in my code. I already knew JUnit 5 was useful for unit testing, but I hadn’t really thought about using it to test for security issues too.

The post talks about how developers can use regular unit tests to check for vulnerabilities early on, instead of waiting until the very end of development. It explains different strategies, like testing bad input, enforcing boundary checks, and even trying to break your own code to make it stronger. The idea of using parameterized tests to throw lots of different attacks at your code really stood out to me. I liked how the blog makes it so straight-forward.

Reading this made me realize I thought of testing as a question of”does it work?” — not “is it secure?” I like the idea of making security testing part of the normal coding routine, instead of something extra you only do if you have time. It’s a good reminder that security isn’t just about firewalls and encryption; it’s about the small choices you make in everyday code. The blog really emphasized that testing for edge cases and unexpected behavior can be just as important as making sure the “happy path” works.

One thing I found especially interesting was how JUnit 5 makes it easy to run the same test with multiple different inputs using parameterized tests. I had used this feature a little bit before for checking different types of valid inputs, but I hadn’t thought about using it to simulate attacks or unexpected bad inputs. For example, passing in SQL injection strings or unexpected data types could help catch vulnerabilities early before they become serious security problems.

I also liked how the blog encouraged starting small, not talking about designing a full-blown security test suite right away. Even adding a few security-focused tests for each feature you write can slowly build a stronger, more resilient application over time. It made me think about how easy it is to treat the idea of “security” as something separate from “normal” code and how easy it is to break it down into a couple tests per feature makes it much more manageable that coding the project and then trying to apply security testing.

In my future projects, especially ones involving databases, user input, or authentication, I want to make sure I’m thinking about security from the start. Testing with bad input and thinking like an attacker isn’t just for cybersecurity experts — it’s something every developer should get comfortable doing. Using JUnit 5 for this feels like a natural extension of skills I’m already using.

Overall, this blog post made security feel a lot more approachable. It gave me some simple ideas I can apply right away, and it motivated me to be a little more critical and thoughtful about the code I write, not just whether it works, but whether it’s strong enough to handle real-world problems.

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.