Link to blog: https://dzone.com/articles/top-10-software-architecture-patterns-to-follow

Recently, we have covered a few different types of software architecture, namely Monolith, Client-Server, and Microservices. While these each have their respective use-cases, I wanted to explore more possibilities for the architecture of a software. Because of this, I have found the Top 10 Software Architecture Patterns to Follow in 2024 by Lucas Lagone. 

Lagone establishes a format to his top ten list by describing the overview, benefits, and use-case for each item. His number 1 software architecture pattern is layered architecture. According to Lagone, layered architecture (or the N-tier architecture), divides the software into several layers each responsible for their own functionalities (Lagone). This type of architecture encourages modularity, allowing for independent development of different layers of the software,  and can be utilized for a variety of types of applications (Lagone).

Lagone continues his list, discussing the rest of the architectures below:

• Serverless Architecture
• Hexagonal Architecture
• Event Sourcing
• Model-View-Controller
• Microservices Architecture (covered!)
• Service-Oriented Architecture
• Event-Driven Architecture
• Repository Pattern
• Reactive Architecture

Lastly, Lagone writes about how one can choose the right architecture for their needs, and what factors come into play. Some of these factors include the complexity of the problem domain, the project’s requirements and goals, the scalability of the project, security, team expertise, etc. (Lagone). 

I selected this resource because it is a recently written (November 2023) article that is a good reference for an updated list of software architectures currently in use. It’s a great resource that clearly gets the point across for each item in the top 10, whilst being a short enough read to be a good refresher for those unfamiliar with the information. 

Personally, I found this to be the perfect article for me to quickly learn more software architecture patterns. It doesn’t go too deep into the software jargon and terminology that only an experienced professional would know, yet it still talks to you in a way that assumes you are an educated yet learning individual. I really liked the formatting of the top 10 list, as it gave organization, purpose, and distinction to each of the items. I learned many other types of architecture, and specifically what to consider when selecting a software architecture pattern for your project/team. This is probably the most important part, as choosing an incompatible pattern for your needs could set you back even further than you were before. I hope to apply this to future jobs where I can contribute to the selection of an architecture based on this knowledge.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Link to blog: https://www.computer.org/publications/tech-news/trends/application-security-testing

The whole semester we have been exploring various ways of testing code, namely styles that ensure the code works as it should. However, there is another aspect of testing we have not discussed yet; security testing. 

It is of the utmost importance to ensure that your software, database, website, etc. is safe from hackers and leaks. Security testing would help just that: making sure your system is unbreakable, or at the very least mostly protected from vulnerabilities and flaws. I think it is important to learn about this aspect of testing, which is how I came across Adam Stead’s article What is Security Testing? How to Check The Security Strength of Your Application.

Stead stresses the importance of security in software and also lists some important security testing techniques, such as vulnerability testing, black box testing, penetration testing, and more. There are many benefits of security testing besides identifying vulnerabilities. Some examples listed by Stead include protecting sensitive data, enhancing customer trust, and cost-effectiveness. Data leaks have been pretty common as of the past several years and it is a huge deal for those companies to lose their customers’ trust and their own reputation. With increased security comes increased trust, which is beneficial to both the business and the customer. 

Stead mentions some security testing best practices, and reinforces the idea of starting early and prioritizing risks. Security testing early on in development can help prevent flaws in your code, and you should continue to test throughout production. Prioritizing risks ensures that your important flaws don’t go unnoticed, and you fix your biggest holes before fixing the smaller ones.

Stead ends the article by discussing some attributes of effective security testing (thoroughness, continuity, scalability, etc.) and stresses the importance of checking the security strength of your software regularly.

I selected this article because this is a topic we have not discussed much in class even though it is still a very important part of software testing. This article emphasizes the key elements of security testing and how important it is to include it as a part of your testing regime.

The content of the resource was very informative and understandable for someone who already has a bit of understanding of software testing. An interesting thing I learned was about fax online, which is a method that businesses use to securely send documents. I did somewhat enjoy the article, it was informative, however I wish it included some examples of certain testing types. I expect to apply my newfound security knowledge to future jobs and software practices.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Link to blog: https://medium.com/swlh/intro-to-javascript-testing-with-mocha-1366dad9b973

For the next (and last) couple weeks of class, we are required to create our own in-class activity as if other students were going to use it. We were tasked with choosing something different than we have done already, so my group decided on testing JavaScript programs with the Mocha framework. I personally have no experience with Mocha, but I do have a tiny bit of experience with JavaScript, so I was interested to learn more about how different testing looked compared to what I was currently experiencing. This is how I found Valerie Foster’s blog post Into to JavaScript Testing with Mocha. Here’s what I found. 

Foster does give a few instructions on how to install the Mocha framework to your project, but I’ll mainly focus on the pros and cons of testing within the framework. They include a codeblock of a simple test, however it was not 100% clear to me at first what each line meant. Here are a few things included in the codeblock, and what they do:

• describe(string, function)
  • According to Codeacademy.com, the describe function groups tests together and uses the first parameter, the string, to explain that group. The second parameter, the function, is a callback function which has ‘it’ tests (I’ll get to that in a moment)
• it(string, function)
  • The it function is similar to the describe function, as its parameters are the same. However, the string it accepts is instead used to explain what the test itself is checking for. So, for example it(‘should //do something when //condition’, function(){})

Foster then discusses some customization options for Mocha, but then specifies their favorite assertion library in Mocha, called chai. One of the key benefits of this library is that it might make the test functions easier to read (e.g., going from assert.equal(a, b) to expect(a).to.equal(b), according to Foster). 

I selected this article because I wanted to have more of a background on Mocha and testing with Javascript since it is going to be our project. Also, Foster seems capable and comfortable with Mocha and JS, and makes it easy to understand what is going on in tests with a framework I’ve never seen before. A good beginner’s guide is always helpful to a fresh start.

I liked this blog because it felt informative and informal; like I was being taught something new but not in a super serious tone (Foster shared their favorite terminal customization was a Nyan Cat reporter). I learned a bit more about how testing is done in JavaScript, including describe and it functions. This affected me by boosting my confidence in my ability to assist my group with our assignment and it encouraged me to learn more JS and Mocha as a whole. I expect to apply such learned knowledge to future web applications and perhaps even past projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Based on this article by Denis Kranjcec: How I failed at Test-Driven Development and what it took to get it right

For the past couple weeks, Test-Driven Development has been the focus of our learning. We’ve done a small project in class creating a simple rover instruction program, which built our confidence and knowledge on how TDD works. Then, we used what we learned to individually create a unique word counter with string input. Since then, I have taken a slight liking to TDD, although it may just be a honeymoon phase. Well, my last blog post was about why Test Driven development is so good. This time, I sought out to find peoples’ personal failures with TDD, and why it failed. This is how I found How I failed at Test-Driven Development and what it took to get it right by Denis Kranjcec. 

Kranjcec begins his article by summarizing that he took a shot with TDD, and missed. But why did he miss? He dives into the reasons, and after a quick discussion on what TDD is and how it is supposed to improve code, he came to the conclusion that it wasn’t TDD’s fault, it was his. 

To start off, Kranjcec was using DDD (Domain-Driven Design), which led to his code being easy to comprehend, but his tests were more complex and difficult to maintain. After trying TDD again, he eventually realized that his biggest mistake was “starting with the simplest use cases and building up to the more complex ones” (Kranjcec). This seems to be a common problem with TDD users, as they tend to stick to more complicated tests than easier ones in exchange for fewer tests total. 

His solution was to change the way he wrote code and designed. This was done by breaking his work down into many smaller steps and lots of commits each day, in addition to refactoring his code. In short, he noticed his code was much simpler to understand and shorter, with other benefits as well.

I selected this article because after only seeing the benefits of TDD, I wanted to see the struggles people had with it. Although this article wasn’t about the faults of TDD, it shows the personal mishaps or mistakes that one can make when working with TDD, which can lead to a greater understanding of it in the end. 

I did like this article because it was an alternate perspective on how TDD can go. I learned to be patient with my code, and to try and stick with simpler tests and design in order to make TDD more effective. I think this article is a good reminder for self reflection on your own work, as it may not always be another’s fault if it doesn’t work. I hope to apply such knowledge in future projects using TDD, keeping in mind that simplicity is key.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Article: https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

Last class, we got some hands-on experience with using Test Driven Development. These concepts always feel more concrete and understandable when actually working with them  yourself, rather than only reading articles or looking at examples. I’ve since gotten the hang of this method of development, and wanted to look into how it compares with other development strategies. Such is how I found Test Driven Development is the best thing that has happened to software design by Arek Torczuk.

Throughout the entire article, Torczuk compares the methodologies of code-driven tests and test-driven code. In other words, he judges whether code-first test later is better than test-now code later, respectively. The results for this vary, of course; some companies or teams may benefit more from one strategy than the other. A noted flaw of code-driven testing is that your tests do not challenge the implementation and design of your code. You can create all the tests you’d like on a specific method, but nothing would make you second-guess the way you wrote the method. 

This is where the test-driven approach would come into play. Having already written the tests, you have a better idea of what your code should look like, and how it should act. As Torczuk states, you can ask yourself “What do I expect from the code?” with writing tests before the method (Torczuk). Essentially, with TDD, you know all the answers to your questions and when enough is enough in terms of tests & code. In my mind, it makes the process more streamlined.

Another important part of TDD Torczuk mentions is that it gives quick feedback about the design of your software. You’ll sooner realize the potential issues with your existing codebase, and how it might affect your ability to add new functionality. 

I selected this article because test-driven development piqued my interest after I had more time to experiment with it. This article grabbed my attention specifically because it didn’t just reiterate the concept of Test Driven Development over and over. Another quite useful part of this article is its inclusion of real examples of TDD by the author.

The content of this article was clear cut and organized, and even though it may not have been a ton of new information, it was a different perspective comparing test-driven development and code-driven tests. I learned that generally TDD is more effective at producing well-implemented code than simply writing the method first and tests later. Seeing as we are continuing to learn TDD, I’m confident that I’ll be able to use this in my future projects/jobs if necessary. Or, I could suggest it to my team if we are struggling with writing tests after code.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In class, we began learning about the use of mocking in software testing. After doing an activity, I realized I only slightly understood the purpose of it. So, I decided to investigate, which is when I found The Art of Mocking by Gil Zilberfeld and Dror Helper.

The article begins by giving an introduction to unit tests for those who might not be familiar. They also give an example in C#, which is the language they use for the rest of the article. However, this does not impact information about mocking besides the syntax of the examples.

Once unit tests are covered, hand-rolled mock tests are introduced: they are classes that the developer(s) code which take the place of the real objects for testing purposes. It might not accurately test the system, but it ensures the business logic of the class works. 

The types of mocking listed are those manually made by the developers and those auto generated by mocking frameworks (Mockito or Moq). The article goes quite in depth into mocking frameworks, in their types, what they do, and what to look for when choosing one. Zilberfeld and Helper also discuss the benefits of mocking, which generally boils down to the fact that mocking cuts loose extra requirements for testing, such as databases and other external/complex resources.

Lastly, the best practices and potential hazards are listed. From what I gathered, the important ones were:

• Only use fake objects when necessary, as too many can create weak/fragile tests
• Understand what you’re testing and the dependency
• At most two assertions/verifications per test

I selected this article because I was struggling a little bit with what mocking was and why it was useful. I had somewhat understood the concept and the idea behind it in class, but needed to go on a deeper dive to get a better grip on it. This resource also seems pretty real, in the sense of it feels homemade and focused; all the important stuff is in the articles themselves, not a subscription or anything. 

This article is superb with its examples and clear, in-depth explanations of unit tests and mocking. The formatting is easy to follow and allows for smooth learning and transitions from concept to concept. I personally believe that mocking is quite useful when applied lightly. I learned that Verify should only be used in fake objects when it’s the only way your program can pass or fail; otherwise, it might not matter whether every method actually calls the expected method. 

This affected me in a positive way as it gave me greater insight to mocking and more confidence in my personal understanding as to why we use it. I expect to apply this in a future job when I might need to test a method that uses database information, but it would take too many resources to use the database for testing purposes.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://web.dev/articles/ta-test-cases

Last week, we tracked the path a program would take using program graphs. The program graph is good to represent the overall structure of a program; it shows all the ways the code can go. 

Afterwards, I wondered about the other types of paths a program could take, whether it be the best case, worst case, etc. That’s when I found Ramona Schwering’s article about test cases and happy paths.

Although I primarily read this article for it’s definitions and information on the different paths a software could provide, it also covers the idea of a test case and how to prioritize the right ones. Schwering first reminds us what a test case does whilst checking the results of the program: it verifies the program does what it’s intended to do, and it validates the program is what the customer or user wants. 

Next, Schwering explains what drew me to the article in the first place: test paths and their outcomes. The first path is known as the happy path, since it applies to the most common use case of your program; this is what should happen and what we want to happen. The second path is the scary path, which is used to catch errors and ugly outcomes. 

Schwering lists other test paths that aren’t used as frequently as the first two but could be important to recognize. I’ll talk about a few I find interesting.

• An angry path is supposed to get an error; making sure error handling works.

• A desolate path would be important for programs dealing with input data, as it tests to see if it’s given enough data to function correctly. 

Lastly, Schwering goes over the best practices for writing test cases, and how there are two patterns used to structure the cases: Arrange, act, assert and Given, when, then.

I selected this article because it covered my topic of interest and I also enjoyed Schwering’s straight to the point, easy to understand writing style. I decided to do a deeper dive on Schwering herself and found she’s a software developer and tester that speaks at international conferences worldwide. Reading through the post, I found the organization of the information to be helpful in my learning along with the information itself being reflective of my thoughts on our recent classes. 

The content Schwering provides in this article is great for a quick read for anyone wanting to learn more about testing. I personally believe the paths she went over are important to prioritize, especially happy and scary paths. I refreshed myself on the duties of a test case and learned multiple kinds of test paths, and how their importances varies from situation to situation. I enjoyed this article especially due to Schwering’s little illustrations and how easy it was to understand the paths. I hope to create test cases in the future with these paths in mind, using them to my advantage when possible.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://www.testbytes.net/blog/boundary-value-analysis

This past week we began understanding and practicing boundary value testing using simple programs and, of course, simple tests. This blog post discusses that same topic, and gives multiple real life-scenarios and dives deep into the subject. Although it is not a super difficult subject to grasp (in my opinion), I feel this is a good way to reinforce those ideas we learned in class.

This blog by testbytes gives all the information one would need to give them a solid starting ground for boundary value testing. It first explains the concept of the testing model and why it would be done, such as explaining how testers hope to identify errors more proficiently. An example is given, using discount percentages that apply ONLY when purchase totals reach a certain threshold. The lower boundary of the first discount is given, testing if the total is less than $10 (which should mean a 0% discount). Then, the upper boundary of the first discount is checked, with a $10 order receiving an expected 5% discount, so on and so forth. 

Later the blog discusses the different types of boundary value testing as well as their distinctions and the disadvantages and advantages of this type of testing. 

I selected this resource because it gives a quick definition of boundary value testing but then goes into further detail on the subject with good examples and explanations. It is a well thought out post that gave me a more concrete understanding of boundary value testing and edge cases. 

Testbytes on its own is a reliable source for this specific information since it is an entire company dedicated to software testing and quality assurance. Through checking out their other posts, I see they have a variety of testing area blogs including mobile apps, web apps, games, automation, security, and more. 

Overall, this resource is great to refer back to due to its consistent information and easy to understand descriptions. 

As previously mentioned, the content in this blog post by Testbytes is a really solid basis for a good understanding of boundary value testing. I can’t say that it is the highest quality and in-depth education on the subject one can receive, but it’s useful for someone like me who is just getting started. 

Personally, I really enjoyed the material, especially the example given at the start. Although I wasn’t struggling with what we were learning in class, there were times where I had a moment of confusion. This is a quick bit of information that instilled some more confidence in me about this topic. One main thing I learned through this blog is a big disadvantage of BVA is truly how many test cases it may require to check all boundaries/edges, which can lead to a lot of effort on the system and more power/time consumption. I expect to use such advantages and disadvantages when creating test cases for my future individual and work projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.