Today I was refactoring some tests to make them easier to write for my application.
In this application, I am testing lines on a subform to make sure they have the correct values. I used a class I created called a FormGetter which uses an interface so I can create a dictionary which contains the values that would be returned by the form.
That’s not what I did today, but was something I’ve done in the past to allow testing to occur without having to actually open up a form and put values into it.
Anyway, you can see in this test method what my new code looks like. It’s easy to see what it’s doing, I think.
I shortened it up because I am using about 12 asserts in this function to run various comparisons. If all of the Asserts pass, this function passes the tests. If not, it gives me a message on the error line to tell me the first assert that failed.
The basic principle is to set up my ECI_JobEstimateLines object which is a controller on my form. I don’t have to attach it to a form for this test because it’s using my FormGetter to just get a dictionary of values. I’m putting them in frmVals which is what is getting looked at by the Jel.Is_Line_Valid function. In the live system on the form, it’s getting the values of those form controls.
So I’m originally populating my frmVals dictionary with values that are valid for a Labor type line using the SetValidLaborLine function. Then before the second assert I am setting invalid values and expecting it to tell me the line is invalid.
I have a long list of business rules and put them all in the test.
Ultimately, this helps a lot. My tests are automated, and when I change the Is_Line_Valid function, i can go back and see any failing tests and adjust them accordingly, or update the validation code accordingly.