Several weeks ago, I mentioned that I’ve been playing around with Property Based Testing. In particular, I’ve been using it with my Angular code. The framework I’ve chosen is jsVerify because it seemed like the most straight forward of the available tools and it has a documented way of integrating with Jasmine, which Angular test use by default. Angular with jsVerify. How does that work?
The documentation for how to use jsVerify seems to be written for people who already understand Property Based Testing from some other environment. This makes picking it up and using it awkward at best.
Over the last couple of weeks, I’ve been experimenting with Property Based Testing. While I’m probably doing it “wrong” by many definitions, I’m finding it useful enough that I’m adding it to my testing toolbox.
I recently reviewed some Angular code that uses one module. The AppModule. To manage the entire code base. And, this isn’t tiny code base. The main excuse I’ve heard for this is that the code originated during the beta cycle, prior to NgModule being added to the framework. I call it out as an excuse because once it was added, it was clear that we needed to have more than one module. The fact that this code base doesn’t have more than one module shows a disregard for doing things right over doing things fast. In the best case, it shows ignorance.
But, the larger question this code base raises for me is this: “Why are more modules better than fewer modules?” After all, using one module obviously works. Isn’t the fact that it works sufficient enough?
And here are three really good reasons to use more modules.
This past week I implemented a pattern I’ve been pondering for almost a year now. I like to create rather modular and granular code such that if my data structures are nested, the components that represent them on the screen should be nested as well. The question becomes, how does one create a reactive form in a child component and attach that form to the parent form in a way that:
Leaves the definition of the child form entirely in the child
Leaves the processing of the data in the parent where the parent form is the “Smart Component” and the child is a “Dumb Component”
Most solutions I was able to find attack this problem assuming the child component will be part of an array of controls. And I suppose, if you wanted to, you could implement that pattern using an array with one element. But, that just felt like a hack. If you are interested in that solution, this is the wrong article.
This past week I had my first need to do use cross field validation in Angular. While the general mechanics are pretty trivial, my particular implementation ran into some issues that you might be interested in.