Property Based Testing in Angular with jsVerify

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.

Here’s what I’ve learned along the way.

Property Based Testing in Angular with jsVerify
Photo credit: Official U.S. Navy Imagery on Visual Hunt / CC BY

Continue reading “Property Based Testing in Angular with jsVerify”

Property Based Testing Revealed – A Better Way to Test

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.

Property Based Testing Revealed - A Better Way to Test
Photo credit: abraham.williams on / CC BY-SA

Continue reading “Property Based Testing Revealed – A Better Way to Test”

Why more Angular Modules are Better than One

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.

Why more Angular Modules are Better than One
Photo credit: goodrob13 on / CC BY

Continue reading “Why more Angular Modules are Better than One”

Attaching an Angular Child Component’s Form to a Parent

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:

  1. Leaves the definition of the child form entirely in the child
  2. 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.

Attaching an Angular Child Component's Form to a Parent
Photo by loomingy1 on Visual hunt / CC BY

Continue reading “Attaching an Angular Child Component’s Form to a Parent”