Sometimes it may be hard to grasp concepts I used for QetriX. You can imagine your application as a sandpit (or “sandbox”, in the original meaning).
Sandpit: Module
Water from a garden hose: Service
Mud pie: Converter
Leaf, petal...: Service?
Sand: Output format (clay, mud...)
I've wrote about TDD (Test-Driven Development), and the truth is, despite how I like the idea, I've never had enough time to do it for all the parts. Well, until now... kinda :-)
A really good documentation is important for the project, along with enough “how to” examples. I've decided to do such examples as a showcase of the component, which is basically to test everything it offers. And then throw some invalid values at it and mistreat it a little bit.
I have to say, I expected this approach to reveal a few bugs, but to my amazement more than bugs it revealed some concept mistakes and forgotten functionalities. That's what I like about TDD, you simply write the test as a “wish”, if you will, how you'd like it to perform, and then try to get as close as possible to the target.
For example, I know I want to be able to abuse items in enums. I want them to support almost anything. So, I started with proper array of objects, then went to array of strings and numbers and ultimately ended up with key-value object, where key is item.value and value is item.text.
I even found a new approaches how to use Components in a different and sometimes more convenient way. I also found the current framework suits me well and I hardly feel there is something that should be done differently.
The main pitfall is I need to create enough unique scenarios, which is sometimes hard to achieve, mostly in cases I need to test uninitialized properties, that are used later for sibling Components. I want to cover as much as possible, without feeling it's all the same.