What is Test-Driven Development (TDD)?

At my organization, we utilize test-driven development (TDD) to develop our software. To get a better understanding of TDD myself, I want to put together a post about what is test-driven development.

What Is a Test?

Before jumping straight into TDD let’s define what a test is. A test is something that verifies that our code works as we expect it to. Typically, this is a procedure or method that executes and asserts that a given valid response is received.

With a test, we verify that our code solves the problem it was intended to solve. That given a particular set of inputs and setup we get back the responses or see the changes that we would expect.

What is Test-Driven Development?

Test Driven Development

TDD can be defined as a programming practice that instructs developers to write new code only if an automated test has failed. Guru99

The above definition is from Guru99. Let’s break it down and I will put TDD into my own words.

The code we develop is driven forward by our test hence, Test-driven development. We write our test first before the implementation has been written. Making sure the test fails and for the right reason. Our test asserts proper functionality. Our test should satisfy the requirements of the software.

We then write the code that makes the test pass. This means our production code is already under test because we wrote the test first.

Red Green Refactor

Red Green Refactor is an important concept in TDD. Above I described how we wrote a failing test this is the red. Then we wrote the actual implementation code to make the test pass this is the green.

We have made it to the refactor step. Now that we have code written that is tested we can feel comfortable to refactor it. Maybe we see code duplication or any number of code smells.

With the tests backing us up, we can feel comfortable modifying the code running our tests and ensuring we are still green.

The simple definition of Test-Driven Development is that we write our tests first. The code is tested from the very beginning. We gain the confidence to refactor and improve our code.

Expect more posts on TDD as I expand my own knowledge of test-driven development!

How to test your EventWaitHandle C#


Warning: Illegal string offset 'id' in /home/thetombo/public_html/wp-content/plugins/oembed-gist/oembed-gist.php on line 96

Warning: Illegal string offset 'id' in /home/thetombo/public_html/wp-content/plugins/oembed-gist/oembed-gist.php on line 96

Warning: Illegal string offset 'id' in /home/thetombo/public_html/wp-content/plugins/oembed-gist/oembed-gist.php on line 96

What is EventWaitHandle

“The EventWaitHandle class allows threads to communicate with each other by signaling and by waiting for signals.”

Problem faced

How do I go about testing an EventWaitHandle. Events are being published threads are flying around the application and I want to test my WaitOn() and Set() calls on my EventWaitHandle.

Why I am using EventWaitHandle

I have a function that displays user data, let’s call it DisplayUserData. But I need to make sure I have all the latest customer data before presenting it. I publish an Event that makes API calls in order to gather all the user data, called GetUserDataEvent, in the beginning of DisplayUserData. I need to make sure that my GetUserDataEvent has fully completed before displaying any data. I have a GetUserDataEventCompleted that I am waiting for. EventWaitHandle is the solution I have to pause inside of DisplayUserData until GetUserDataEventCompleted has been received. Below is a simple sample of what I have currently going on in my code, that needs to be tested.

How to test your EventWaitHandle

Now how can I test this? How can I ensure that the code WaitOne() is working and code is not attempting to access user data before the Set() is called? We will use some threading in our test!

We will put our function call on its own thread. This allows the GetUserDataEvent.Publish() and the WaitForUserData.WaitOne() to occur on their own thread. Our test code can continue and verify what is happening.

Directly after the call to start our thread we want to assert or verify that our code for displaying user data is not being called. This can be tested in a couple ways. It is up to you. But for me, I had a mock of my DisplayUserData and was able to verify that it had not been called yet. For a less advanced approach, you can set input a thread delay and ensure that certain values are still null. Such that they have not been populated with the user data yet.

After we have verified our display code has not been called we can populate our user data with simple test data. This is where the mock comes in because since I had mocked out my actually API call no data was coming back. I simply need to input my own test data. I am not trying to test my API calls at this time I have other tests for that, I only want to be testing my EventWaitHandle.

With our test user data generated we can call, GetUserDataEventCompleted. The subscription for this event calls our WaitForUserData.Set().  We expect that once the Set() is called our Display for the user data will be called once. Below is a layout of our entire test created for EventWaitHandle. This now tests that the Display call on user data does not occur until we explicitly get our Set call on WaitForUserData.

The above works due to mocking using moq library. If you are not familiar with mocking I highly encourage you to look into tutorials on how to use the differen mocking libraries available to you.

For help writing your own EventWaitHandle test leave a comment!