I would like to write about one technic that I use in the AJ_Tools_UnitTest component which is really the core of the component. Actually, when I wrote the component, I literally wrote 5 lines of code to make my component to work. Yes only 5 lines of code was necessary and represent the core of my component, the rest is nothing else but aesthetic and defensive coating.
Let me demonstrate you :
My first method is named "New AJ_Tools_UT_describe" and contains 2 lines of code :
$0:=New object
$0.assert:=Formula(AJ_Tools_UT_assert )
My second method is named "AJ_Tools_UT_assert" and contain 3 lines of code :
$col1:=New collection(This.expected)
$col2:=New collection(This.actual)
This.result:=$col1.equal($col2;ck diacritical)
With this, you are able to do any test you like, but you will need to use the correct syntax for the test object properties and also to manage and parse or log the result by your own.
I wanted my component to do a little bit more, so I have written some code that is able to store the result of every test and to parse it so it will be easy to log it (and to be parsed by an external tool if needed) and to display the result visually, which is important for a developer to quickly see where a test is failing and more important, why !
Let's look at what is great with this code.
I come from JavaScript so the types are not really my biggest friends and I can easily think out of the type jail some developers are trap in. But without the great flexibility of object, we would have to write one method for each type of variable to test.
What I like the most in this code, is that I don't need to care about what type of value will be tested. An object property can have a value from one type and the next line of code, the type can be changed. I already see some hair-raising. This give some flexibility, but it is like some dangerous tools, in some wrong hands, it can lead to some serious damages. So use this ability with great caution. For our case this flexibility allow us to write some really nice generic code that simplify a lot the component by avoiding to multiply many methods only to change the type of what will be tested.
Secondly, why I create 2 collections that contain only 1 value in it? Becaue of the member function : equal. This member function is something that we never had in 4D before, the ability to compare 2 things, no matter the types without having to cast our values. Here everything is automatic and it work so good! It will test if 2 collections are equal and will do a deep equal test, that mean we can even test some complex objects which before was not possible with the "=" equal operator. And this last is truly great because else, we don't have any solution to test 2 objects in a simple way. We could try with JSON STRINGIFY but then, the order of the properties are important because {"a":"a","b":"b"} will not be equal to {"b":"b","a":"a"}
For those who went through the code of the component, you can see that most of the code is only coating and the really interesting part reside in 5 lines of code.
You can find the code of the CORE in the GitHub repository.