Test Driven Development….it admittedly feels a bit tedious to properly execute. …painful might be a more accurate descriptor.

I am a big picture thinker. I am very good at looking at the end goal and seeing the broad-strokes path to get there. This means that I am most comfortable solving problems in (what I thought were normally-sized) chunks of logic. However, TDD is the opposite of how I am most comfortable approaching problems. TDD requires building a solution in the smallest chunks possible from the ground up.  To properly execute it, sometimes you return a fixed value to get a green test rather than do the math. All I can keep thinking is how on earth is typing [return 1] better than [return a+b] when I am going to have to fix it in 3 minutes anyway??

However, despite the pains of execution, I do see that it can be an effective development model when applied in the correct situations.

According to NCrunch, those situations are as follows:

• Pure Logic functions
• A clearly defined set of inputs/outputs
• When defining layers within an application

Likewise, you should AVOID using TDD if….

• Your existing code doesn’t have any tests implemented already
• It is already working

I would also like to add to the list that coding in an exploratory context is not a suitable scenario for TDD. As a student, I often use coding as a medium to work through problems, test different solutions to problems and just explore topics (for example, writing code to draw fractals and messing with it to get a better grasp of how they work). In these types of scenarios, it would be largely a waste of time to take a TDD approach.

Seeing the appropriate times to implement TDD spelled out alleviated a lot of my frustration at the process, as it changed my impression of what TDD was. It was my impression that TDD must be used throughout the entire development process.  Although there are some very passionate developers who would live and die by it, I now see it as a tool that can be used when it is needed.

Additionally, I loved the suggestion to look for places to use TDD. Due to my aforementioned gripes with the process, I don’t see myself jumping to implement it on all my projects. However, I do think I would like to integrate it as part of my development process. (i.e.  I see a lot of value in implementing TDD to create a particular method that does a complex calculation or that modifies a string.) The guidelines above will serve as an effective starting point in assessing when implementing TDD would be the best path forward.

This blog post was written in response to : https://blog.ncrunch.net/post/when-not-to-use-tdd.aspx

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

Mocking is a technique used in software testing where you create a simulated version (a mock) of an object or component to mimic its behavior. This aids in test isolation, faster tests and allows tests to focus in on the targeted part of the system.

In my limited experience with mocking, I have not yet used it to reference anything external to the program I was building. My initial thoughts on it were that mocking seemed like it would be a viable tool to use to circumvent some of the complexity of dealing with external references. After reading the blog post, it became clear exactly why that was wrong.  

In the simplest terms “Don’t mock what you don’t own” means what it sounds like: when you are writing tests, don’t mock anything that you don’t have complete ownership of. This applies to third party libraries and external systems.

Why, you may ask?

1. You don’t own the code, so there is no guarantee about how it will behave in the future. Therefore, mocking it leads to test fragility.
2. Code clarity. When you mock external references it forces you to handle the behavior of it, when your focus should be on the behavior of the application you are working on.
3. Tight coupling. The tests become tightly bound to external code and the system becomes harder to maintain over time.

What should you do instead? Create a wrapper around the third-party code, then mock the wrapper

I found the proposed solution of wrapping the external “thing” and then mocking the wrapper to be a rather elegant solution. This avoids a lot of the coding gymnastics that would be necessary to maintain the “external” mocks. The author of the blog post made a good point, mocking external object creates faster tests, but fast isn’t enough to justify test fragility and poor tests.  This sparked the line of thinking  “What is the goal of this tool (mocking) and how does using it in this way align with that?” This was a new thought process for me. Up until this point in my education, most things I have learned took the form of “Here’s a new thing you can do, now do it”.   This new thought process adds to that the important layer of discernment over my toolbox of skills.  Afterall, you can (in theory) hammer a nail with a screwdriver if you hit it enough times, but you will get some funny looks, and your life would be much easier if you had just chosen a hammer.   In my work, I will be certain to keep this in the forefront of my mind.

TLDR: Only mock code that you own and choose your tool wisely.

This blog post was written in response to : https://8thlight.com/insights/thats-not-yours

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

Test automation refers to the usage of software tools and scripts to execute tests automatically. The goal of this being minimal human intervention and streamlined testing processes.

Automated testing has many benefits (obviously, that’s why it is used):

1. Cost savings – automating tests mean less manpower and resources are spent on manual testing.
2. More accurate results – automated tests are the same every time, leading to more consistency and accuracy .
3. Faster testing cycles – the automated tests are much quicker to execute than manual tests
4. Easier Maintenance – Manual intervention isn’t required, meaning automated testing is ideal for projects tat are evolving frequently.
5. Increased coverage – Automated tests can cover more scenarios than manual tests
6. Reduced human error – this is self explanatory, no manual intervention at execution time means it is far less likely to have human error
7. Parallel execution – executing tests in parallel means faster execution
8. Easy Reporting – Automated tests generate more detailed reports than manual testing. This lets the team identify and address issues quickly and effectively.

However, like anything, automated testing also has its drawbacks:

1. High initial cost and time investment – Automated testing is expensive to set up in both time and money.
2. NO human element – Humans can identify problems that automated testing may not be able to pick up on.
3. Complexity – It is particularly necessary to make sure that the tests are maintainable and structured well. Just because you can run many tests quickly does not excuse poor testing.
4. False Positives and negatives – False results need to be manually addressed.

Other things to keep in mind are that automated testing still needs to be maintained and the performance of the tests needs to be monitored.

As someone who endeavors to someday build a software company, I found this blog post particularly enlightening. It is both human nature and the general industry inclination to rely heavily on things that make manual tasks easier. I don’t think that is a bad thing, it is how many great ideas come about. However, this post highlights the fact that automated testing should be an option that is weighed, not just the default.  On smaller scale operations, the cost to implement it may be too high or it could not be worth the time investment depending on the project. On the other end of the spectrum, it may be a no-brainer for a growing company to spend the money to implement test automation relative to the money they are spending to maintain their current testing. The big take away is to look at the pros and cons before implementing test automation, not just take it as the default. Although I am not in the position to be looking at this type of decision now, I am certain that I will remember this article when it comes up.

This blog post was written in response to : https://www.telerik.com/blogs/is-automated-testing-good-idea-what-should-you-keep-mind

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