This blog is fairly technical but it presents an improvement that may be interesting for some.
In our quest to improve quality of NaroCAD default builds we want to be sure that every time we fix a part, to not break another. For achieving this we need to know that a component is fixed and at which level is achieved this.
NaroCAD have a good separation component that is named: Inputs and Modifiers (or Actions). As we add new components to NaroCAD we want to isolate them, but on the other hand we want to make easier the component finding. For this reason we have define at the action level which dependencies we need. After this, these dependencies will require if needed other dependencies.
One of the changes is that all those cascading dependencies were automatically added to the calling action's dependencies. Right now the calling action will be in contact just with the inputs it asks. Why this is important? Because we can make an action unit test to have less dependencies to setup.
Another change is that the creation of a "fake" dependency is much shorter. This will make easier to make a setup of an action concise. The same of a fake action if there is a need to test a real action input.
The inputs previously were of two kind: Inputs and Pipes. A pipe being an input that depends of another input. For example the Solver component get the mouse 3D coordinate and decide if this point is close(r) with another points or not. But in previous design was not possible to connect to more inputs (even they were needed). This make that at least Solver component to have hard-coded dependencies, that made harder to track some problems (like view flickering) as dependencies were not explicit, but hard-coded. Many of those cases, like meta-actions, were harder to define as they depend on many components of NaroCAD (view, command line, treeview, solver). The big count of dependencies was two fold: they were hard(er) to create unit-tests, but also they are hard to test: our meta-action testing covers just "NaroCAD does not crash" and "it really creates a shape".
The next step is to make possible to create a visual unit testing (that a tester can follow and see if something abnormal will appear) based on NaroCAD typical flows. Also it may make possible to test some components (command line parser for example, that convert your string inserted in command line as a 3D point coordinate, or switch the action) without having to setup a meta-action (that as was said previously, is hard to be made).
After some separation, this code will also remove most probably another limitation of NaroCAD: meta-actions and actions are different entities, and make that for example meta-actions to be accessible from command line, but actual commands to be inaccessible.
So, stay tuned!
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment