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.

In the digital age, we have all grown accustomed to instant feedback from our technology. Old timers love to tell stories of what using the old dial up internet was like, usually paired with “I walked to school uphill, both ways”. It always seems to come with an undertone of kids these days are spoiled. However, I will be the first to admit that when something takes a moment too long to load, my first instinct is to pull up either pull up Task Manager and see what is running or check the wifi-speed. Should I work on being a bit more patient? Yeah. Should we all? Probably.

I digress.

The reason we have grown so accustomed to instant feedback is that it is the standard. Like any standard, how do companies measure and enforce it? Performance testing.

Performance testing is the practice of testing an application, program, or network’s performance. This includes speed, traffic handling, and stability although many other markers fall under this category.

Measuring and responding to performance markers leads to enhanced user experience and by extension increased revenue. For example, when waiting on a website to load and it takes too long, many people will click out before it even loads and look at another site. This directly translates into lost potential revenue due to poor performance.

The most effective way to use performance testing is to integrate it very early on in development. It is far more cost and time efficient to integrate early on in development; the initial set up is far less complex and there is less time needed down the line to rework performance issues, as compared to waiting to implement performance testing. Additionally, it is an effective tool to detect and prevent bugs before they become critical.

I really appreciated the insight this article provided. It is seldom that you think of performance testing when in the early stages of development, unless something goes wrong. Working code tends to be the goal. However, the benefits of doing so are hard to ignore. An important take away from this is that with any code you must consider the user-expectation (I like to think of this as if I am just writing code for myself to solve a one-off problem, I don’t care if it takes an extra few seconds to run my program. However, if I was sharing the program with others, it would be incredibly frustrating to them if my code took forever to execute.)  Additionally, prioritizing quality in the beginning saves many headaches later. Just because you do not test performance in the beginning does not mean you won’t have to go back and fix it once you do.  This is a lesson I will be sure to take keep in mind in the future. This will most likely look like making a conscious effort to make implementation choices that will support efficient performance in the long term as well as prioritizing quality overall.

This blog post was written in response to : https://abstracta.us/blog/performance-testing/why-performance-testing-is-important/

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

Data is the new currency of the digital age. It is constantly being collected, analyzed and sold. Data is an intangible thing; you can’t hold it in your hand. Is it any less valuable than money? I would argue that in some cases, it is more valuable than money. If it is more valuable than money, then there must be bad actors looking to gain access to it. There are. There are more people trying to get into these systems on the daily than all bank robberies in the last 100 years. However, unlike a bank that has a physical vault, data is stored in information systems. So how do you ensure that your data remains secure? By using security testing.

Security testing is an overarching term that refers to the process of identifying and addressing vulnerabilities within a system/application to safeguard data. This can take the form of identifying potential vulnerabilities by looking at code (white box testing), penetration testing (a form of black box testing), among many others.

This makes sense, however businesses are money focused….why do they spend the EXORBITANT  amount of money that they do on security testing?  Afterall, you are not gaining revenue by security testing. It is not  a direct correlation in the way that sales = profits.  According to the blog linked below, it comes down to reputation, financial losses and regulations.

Reputation is pretty self-explanatory: I am not going to be eager to hand over my bank information or social security number if I know that company has been involved in multiple data breaches. There is a necessary level of trust between a company and a customer in order to do business. If I do not trust that my information will be secure, I will choose a different company to do business with.

Financial losses are a multifaceted issue. There are the direct costs: if a company is attacked by ransomware, they will have to shell out $X to attempt to get their systems back. Then there are the less direct costs: the example given was that insurance companies will choose not to insure a company if they keep having security breaches. Choosing not to have adequate security testing means that a company is too risky of a business partner to do business with. Once a company loses insurance coverage, it is not a rosy outlook for the future. Insurance companies run the world.

Finally, in order to be commercially viable, software needs to meet regulatory security standards. This could be on an industry, state or international level. The need for enacting regulatory standards illustrates just how important security testing is.

Moral of the story: Security testing is about spending money to not lose money and being a good digital citizen. You need to protect everyone else’s information as if it were your own.

This blog post was written in response to : https://sdtimes.com/test/the-importance-of-security-testing/

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

Functional testing is testing that focuses on how the code behaves in relation to technical and business requirements. It boils down to caring about what the system can do, not how it does it.

In comparison, non-functional testing is a broader term that encompasses basically everything else. This includes security testing, performance testing, usability testing, stress testing etc…

As an example, say I built a calculator program …

Functional testing would look like checking if 1+1 = 2 and 45/5 = 9

Non-Functional testing could look like testing how long it takes to calculate simple integer addition or making sure that no outside users could hack in and access your calculation history.

The key distinction between the two is the types of answers you can from the type of testing. Functional tests often tell you yes or no (does it do x when I do y?). Non-functional testing tends to give answers that are evaluated on a scale (How long does it take when..? How easily will the user be able to access this?)  

I found this article to be quite informative. It clarified in my mind how the two types differ. Although I am familiar with functional testing, I was not familiar with what falls under the umbrella of non-functional testing.  Generally speaking, it is often the case that as programmers we focus on functional testing. This makes sense, as working code has to do with input/output relationships. However, after learning about non-functional testing, I see why that is flawed. Non-functional testing represents the next level up in the hierarchy from the code. You can have working code that is objectively awful code. In order to improve your code, you need to pay consideration to the metrics of non-functional testing to assess how your code is performing, not just what it is performing. I can see how this becomes of particular importance once we start talking about a business level view-point rather than just a code/project level one.

As someone who hopes to found their own software company one day, this is particularly important. It illustrates the jump from code to business in testing metrics. I always have placed particular emphasis on learning computer science through the lens of that goal. Exploring this testing topic allowed me to identify a new point along the aforementioned seam between code and code for a business.

Additionally, understanding the different classifications of testing gives you the context to build better testing systems. Now that I know about functional vs non-functional testing, I will be able to analyze my own projects through that lens. I may think I have pretty solid testing in place for a piece of code, but upon further inspection I realize that I only tested what the code does, not how fast it will perform. Or vice versa, I may look at a project and realize that I was focusing so much on performance that the granular details of the code do not implement an elegant solution.

This blog post was written in response to : https://u-tor.com/topic/functional-vs-non-functional

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

Behavior Driven Development (BDD) is a software development approach that focuses on how the end user will interact with the application. This was created as an extension of Test Driven Development in an effort to bring customers into the development process in a meaningful way.

However, according to the article linked below, BDD is more about a philosophy and communication than an actual framework. The main complaints listed are than “Clients don’t care about testing” and “The client doesn’t want to write the specifications”. However, what these complaints fail to address is that BDD is a way to bring customers directly into the development process. It is not about writing their own specifications, it is about truly understanding the user experience and how we can directly support that throughout the development process.

As people on the technical side, it can be quite easy to get caught up in the nitty gritty details of what you are working on. Consequently, it is sometimes easy to lose sight of the bigger picture (aka, what product the customer will be interacting with). What BDD aims to do is bridge the gap between the developers and the users and inject the user directly into the middle of the development process. In essence, it is a tangible way to always have the customer in the room.

This is conceptually something I really agree with. It is the equivalent of a student pasting the assignment requirements at the top of the page before beginning to work (something that I have often done). It keeps your focus on the things that matter and contributes to an effective and efficiently developed solution.

Something that struck me about the post was this question that was posed: “How complicated would it be for you to explain to a 3 year old child how a bank transaction works?”  It served to highlight that part of the value in BDD is that on the tail end, it facilitates effective communication back to the customer. Just as with the 3 year old, a customer does not need to see the test cases that test the granular detail of the code, they just need to see what it does. This means that the tests used in BDD can then be used to demonstrate the behavior of the code in an easy to understand, non-technical format.

I was previously unaware of the value in BDD for communication until reading this post. I think that effective communication is something that is hyper-emphasized on the business side of things, but can be lacking on the technical side. The ability to integrate the customer into the testing structure and then communicate the testing back to them enhances the quality of collaboration and the end-product.  I am eager to delve deeper into other development practices that specifically support development by bridging the communication gap between developers and customers.

This blog post was written in response to : https://www.thoughtworks.com/insights/blog/3-misconceptions-about-bdd

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

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

In the simplest terms, Test Driven Development is a development strategy that involves writing a test first, then writing code only to satisfy this test (without breaking all the previous tests). Simple enough.

The problem with this? Many programmers have a love hate relationship with Test Driven Development.  In certain cases it can be an effective development strategy, however, it is feels slow and is tedious to properly execute. Given this, why do we use it? What is the real value in using this approach?

Uncle Bob would argue that it is the short development cycle that is most important. Writing the tests first requires that the development cycle increments are pretty much as small as possible. It is a way to enforce on a process level that developers break down their work into small and manageable pieces. This goes against the very natural inclination to solve the problem not a piece of the problem. This is why it needs to be addressed on a process level. TDD has nothing to do with the tests being written first, it has everything to do with writing the test first defines a small increment to code.

This is good news for the TDD haters, you don’t have to use TDD specifically. However, you should take a lesson from TDD and consider how you can apply it to your development process. Uncle Bob specifically notes that Test Last Development (TLD) has a similar effect to TDD.

As I am still new to TDD and still working through some katas, I will continue to do that. However, I personally think I will fall in with the group that should take a lesson from TDD and move on. I sometimes struggle to start working on a problem when I am looking at the problem as a whole or when I get stuck, so I really liked the way that TDD makes you put one foot in front of the other and just take the next step. However, I did not like that it can get in the way of being in a “flow state” of coding. I really enjoy it when I am coding and I am in a groove. That is a wonderful feeling. In that way, TDD feels like it sucks the joy out of coding. Uncle Bob’s analysis of TDD will inform my development process in that I will work on finding a way to implement small development cycles in a way that works for me. That might look like writing the tests first sometimes or it might look like mentally breaking down a problem in a TDD-like manner. However, I feel the freedom to learn from TDD without being pigeon-holed into using it exclusively just to get the benefits of it.

This blog post was written in response to : https://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html

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