Unit testing code that is spawned as a separate thread can be challenging.

We need to make sure our Asserts can run after the parallel thread completes, and not before.

Moreover, we need to make sure our unit test doesn’t complete before the parallel thread, leaving it orphan and causing errors for the test agent.

Consider the following code:

        private void LoadCustomerData()
        {
            this.IsLoading = true;

            // the following code will run a separate thread (use a BackgroundWorker if you like)
            Task.Factory.StartNew(() =>
                                      {
                                          // do some stuff here to load the data
                                          this.Customers = dao.GetCustomers();

                                          // finally indicate that loading is completed
                                          this.IsLoading = false;
                                      });
        }

Now consider a unit for this:

        [TestMethod]
        public void LoadData_should_bla_bla()
        {
            // Arrange
            var testObject = new SomeClass();

            // Act
            testObject.LoadData();

            // Assert
            Assert.IsNotNull(testObject.Customers);
        }

The test looks pretty straight forward. However, when you run this, it’ll not pass. You’ll most probably get the “agent terminated before execution completed” error or your assert will fail.

The reason is this: this.Customers is set by a separate thread, and as soon as you call LoadCustomerData(), it spawns that thread and returns immediately. Giving no time for the actual load to happen before you can do your Assert. In other words, your assert runs before the thread that loads the data.

OK, how to we solve this? Well, my first attempt would be to wait before I assert:

        [TestMethod]
        public void LoadData_should_bla_bla()
        {
            // Arrange
            var testObject = new SomeClass();

            // Act
            testObject.LoadData();

            while (testObject.IsLoading)
                ; // do nothing till loading completes

            // Assert
            Assert.IsNotNull(testObject.Customers);
        }

Again, at first look this looks pretty straight forwards. Your test would also work pass now. However, you’ll hit trouble when the test fails. What if something goes wrong when loading and IsLoading is never set to false. Well, your test will run indefinitely!

Ideally, your test should fail if for some reason IsLoading is not set to false. So, we could try a “wait with timeout” approach. Instead of waiting indefinitely, we can wait for some time (say 2 seconds) and throw a timeout exception after that (which will make the test fail). May be something like this:

        [TestMethod]
        public void LoadData_should_bla_bla()
        {
            // Arrange
            var testObject = new SomeClass();

            // Act
            testObject.LoadData();

            // Wait until IsLoading becomes false or for 2 seconds, whichever occurs first
            TestUtility.WaitWithTimeout(() => testObject.IsLoading == false, 2000);

            // Assert
            Assert.IsNotNull(testObject.Customers);
        }

There you go. This would work!

And here’s the code for this WaitWithTimeout function:

    class TestUtility
    {
        internal static void WaitUntil(Func<bool> whatToWaitFor, int howManyMilliseconds)
        {
            DateTime start = DateTime.Now;

            while (!whatToWaitFor())
            {
                Thread.Sleep(100); // just breathe a little instead of a continuous loop!

                if (DateTime.Now.Subtract(start).TotalMilliseconds > howManyMilliseconds)
                {
                    throw new TimeoutException("Wait timed out");
                }
            }
        }

Cheers!

-Anand

        private void LoadInitialData()
        {
            Loading = true;
            Task.Factory.StartNew(() =>
                                      {
                                          if (BranchTeams == null) // we only need to load first time
                                          {
                                              LoadBranchTeamData();
                                              if (App.StartupSurveyId > 0)
                                              {
                                                  SurveyFilter = App.StartupSurveyId;
                                              }

                                          }

                                          ApplyFilters();

                                          Loading = false;
                                      });
        }

        [TestMethod]
        public void LoadData_should_bla_bla()
        {
            // Arrange
            var testObject = new SomeClass();

            // Act
            testObject.LoadData();

            // Assert
            Assert.IsNotNull(testObject.Customers);
        }

Often while writing an application or adding a module to an existing application we wonder if we should go with multithreading. Multithreading can be a powerful tool, but only if used the right way. Lets examine.

There are two main reasons when one should consider multithreading,

1. We have a GUI application and want to improve the user experience.
2. We have a batch job processing application and want to improve the performance.

Lets take the first situation. I have developed a desktop application which splits large files into smaller chunks. I choose a movie file and want to split this into smaller chunks. Depending on the size of the file this operation may take anywhere from few seconds to few minutes. Lets say in the middle of the operation, I realize I chose the wrong file. If my application is single threaded I cant do anything to stop this as the main thread is working away splitting the file. So, if my application uses one thread, I can do only one thing at a time.

Now it makes sense to have this application multithreaded. You can start the file splitting on one thread while you have the main thread listening to user inputs. The thread doing the splitting work can be interrupted in case the user cancels the operation or needs to do something else.

So, writing GUI applications with multithreading makes a lot of sense and almost all modern day applications are multithreaded.

Now lets take the second scenario. We have a batch processing job to do. We have a bunch of xml files which we have to parse and persist in a database. If I do this operation in my main thread, I would have to parse each xml file and put the data in database sequentially. If I want to speed this process up, the logical thing to do would be to process these files and update the database in parallel. But its not that simple, there is a catch.

One CPU can process only one thread at a given time. There is also an overhead involved in thread scheduling as time slicing will be done to give CPU time to different threads. So if 50 threads are started to process 100 files, the job will definitely slowdown on a single CPU machine. At the same time doing the process in one thread does not make sense as the process involves i/o and db operations which are time consuming. A thread waiting on i/o is automatically removed and another thread is given a chance by most operating systems today. So the ideal number here would be around 5 threads. In case the environment has more than one CPU, the number of threads can be increased. This can even be decided at run time. The number of CPUs available for the VM can be got from the Java API Runtime.getRuntime().availableProcessors(). This can be multiplied with a suitable factor to get the number of threads required to process the job.

Multithreading for batch jobs should be considered based on the platform on which the process runs. Even better would be to have this configurable at run time.

It is good to consider the above while developing multithreaded GUI or batch jobs. In case we didn’t get the required performance, we now know where we were going wrong.