update footer year and formatting in tdd blog

Author: vjdhama

config.toml

@@ -57,7 +57,7 @@ enableRobotsTXT = false
     summary_large_truncate = 120 # How many characters to include in the summary of the team bios (large layout) before truncating
 
   [params.footer]
-    copyright_text = '© 2023 Infraspec - Delivering high impact transformational work'
+    copyright_text = '© 2024 Infraspec - Delivering high impact transformational work'
 
 [menu]
   # Main Menu

content/blog/tdd-design-benefits.md

@@ -18,38 +18,44 @@ As defined above, we write unit tests even before we write the code. This might
 To make this easier to understand, try to think of it like this. It is not testing but stating what you expect the code to do. With this, you are trying to put your expectation before writing the code.
 This shift in mindset, helps you be very clear and concise about what you want and how you want your software to behave.
 
-Since we don't have any code to test, this inversion of thought process and development style now poses a few interesting questions.
+Since we don't have any code to test, this inversion of thought process and development style now poses a few interesting questions:
+
 1. What do we expect from the function and how do we want it to behave?
 1. What should be the function/method name? What would make sense from the caller's perspective?
 1. What would be the Class name in the case of Object Oriented language?
 1. What does the function need as dependencies for it to perform its task?
 
 Let's see how these questions help us one by one
+
 ### Q1: What do we expect from the function and how do we want it to behave?
+
 Answering this question helps us to focus on the exact intended outcome before implementing the code. 
 This enables us to break the problem statement into smaller chunks as we need to test for each expectation separately. 
 This helps us build the software incrementally, and discover edge cases by asking how should it work for weird input values.
 
 ### Q2: What should be the function name? What would make sense from the consumer perspective?
+
 Since we would be having the consumer of the function even before it is implemented, it forces us to think of a good function name.
-This helps us in understanding how different pieces of code will use this new function. 
+This helps us in understanding how different pieces of code will use this new function.
 This significantly improves readability and guides us to arrive at meaningful names.
 
 ### Q3: What would be the Class name in case of Object Oriented language?
-Naming as we all know is one of the hardest things for software engineers. 
+
+Naming as we all know is one of the hardest things for software engineers.
 One thing I have realised over the years is naming in a meaningful manner only takes iterations.
 But one easy way to get started in the right direction is to name things from the consumer's point of view.
 What this means is when we start to think from the consumer's point of view, it starts becoming clear as to how it could be used.
 And test cases are the first consumers of the code.
 This like the previous one helps us improve readability ad arrive at meaningful class names.
 
 ### Q4: What does the function/class need as dependencies for it to perform the task?
+
 When we write code, we sometimes expect certain things to be present or need to be passed in for the new code to work.
 This helps us understand how complicated the code setup could be if it needs a lot of things.
 This acts as an indicator and surfaces tight coupling if any early on in the development lifecycle.
 We could consider this as a tool which would prevent the design of the system from having high coupling and reduce complexity.
 
-> ### TDD is not just about having tests but a lot more than that. It not only helps us verify the correctness of the software but if practised well, helps us design the software well. This is why I sometimes think of TDD as **Test Driven Design**.
+> ### TDD is not just about having tests but a lot more than that. It not only helps us verify the correctness of the software but if practised well, helps us design the software well. This is why I sometimes think of TDD as **Test Driven Design**
 
 All of this sounds too good, but it's easier said than done.
 Here is one of the many reasons why people are not able to successfully adopt this practice into their development lifecycle.