You write a test for the behavior you want. So far so good. You have to figure out how to interface with your system to write the test though.

Today, I was adding a new type of status called “Internal Hold” for an order, and the line items each can also have that same status. So to make sure the status existed, I started off by writing a test to make sure my constant was set. Something like:

Does STATUS_INTERNALHOLD = “”? If so, fail.

That was a pretty easy test to write (I’m using RubberDuckVBA unit testing. You can search my blog for TDD or RubberDuck and find out how to install and use it).

Then I wrote a test for my ECI_Status module to make sure it was returning the new status in the GetRowSourceList function. Again, pretty straightforward.

Next I started looking at where the constant STATUS_VENDORPROBLEM was being used because I am to ensure that the same business rules apply to the new status as they do to that status.

Herein lies the problem. I wanted to make sure that if there are any lines in an order that have that status (STATUS_INTERNALHOLD), it should change the order status to the same thing (STATUS_INTERNALHOLD)

So in my status object, I already built in a status wrapper so that I could write different functions. My first instinct was to create a new fake status wrapper that would just return the status I want when I call the function I am running (GetOrderStatusBasedOnLineStatuses).

That function normally is passed an order ID which then looks at the lines and checks to see if any conditions are met that should change the order status.

But if I fake that function, all I am really doing is creating a fake that will make my test pass, but it will never actually get used in the real application. What I really want to test is an internal private function inside the status object that looks at status counts using a dictionary and returns the correct order status. It’s called ( ProcessStatusRules ) and it takes a Scripting dictionary and a CurrentOrderStatus string. This would be super easy to test if I could simple access it directly. And I want to make sure that the only thing I’m faking is the return of data from the database. Both the live system and the test should be using the same code to process the status rules.

So what this tells me is that I need a seam between the status object and the database. I also am seeing that in order to do this, I likely need to break up my status object into a larger number of objects.

FYI, in order to better learn and understand TDD, I am adding a weekly todo for me to work on one feature of an app using TDD. So far so good.