G'day:
I started back on the next article of my VueJS / Symfony / etc series this morning. And now it's 18:24 and I've made zero progress. Well I've written a different blog article in the middle of that ("TDD & professionalism: a brief follow-up to Thoughts on Working Code podcast's Testing episode"), but that was basically just a procrastinary exercise, avoiding getting down to the other work.
I'm currently laughing (more "nervous giggling") at my mental juxtaposition of "TDD & professionalism" from that earlier article and the title of this one. I'm not feeling very professional round about now.
OK so I sat down to get cracking on this new article, and the first thing I did was re-run my tests to make sure they were all still working. This is largely due to some issues I had with the Vue Test Utils library about a week ago, which I will discuss in that next article. Anyhow, everything was green. All good.
Next I opened my Vue component file, and remembered a slight tweak I wanted to make to my code. I have this (in WorkshopRegistrationForm.vue):
submitButtonLabel: function() {
return this.registrationState === REGISTRATION_STATE_FORM ? "Register" : "Processing…";
},
I'm not in love with those hard-coded strings there; I want to extract them and use named constants instead (same as with the form-state constants I already have there).
The first thing I did was to locate the test for when the button switches to "Processing…", and update it to be broken so I can expect the change. Basically I figured I change the label to be something different, see the test fail, update the code to use a constant with the "different" value, see the tests pass, and then change the test back to expect the "Processing…" value, and then the const value in the code. Sometimes that's all a test change that's needed. And in hindsight I'm glad I did it.
The test method is thus (from test/unit/workshopRegistration.spec):
it("should disable the form and indicate data is processing when the form is submitted", () => {
component.vm.$watch("workshops", async () => {
await flushPromises();
let lastLabel;
component.vm.$watch("submitButtonLabel", (newValue) => {
lastLabel = newValue;
});
let lastFormState;
component.vm.$watch("isFormDisabled", (newValue) => {
lastFormState = newValue;
});
await submitPopulatedForm();
expect(lastLabel).to.equal("Processing…");
expect(lastFormState).to.be.true;
});
});
The line in question is that second to last expectation, and I just changed it to be:
expect(lastLabel).to.equal("Processing…TEST_WILL_FAIL");
And I ran the test:
[=========================] 100% (completed)
WEBPACK Compiled successfully in 3230ms
MOCHA Testing...
Testing WorkshopRegistrationForm component
Testing form submission
✓ should disable the form and indicate data is processing when the form is submitted
1 passing (52ms)
MOCHA Tests completed successfully
root@9b1e15054be3:/usr/share/fullstackExercise#
Umm… hello?
Note: in the real situation I ran all the tests. It's not just a case of me running the wrong test or something completely daft. Although bear with me, there's def some daftness to come.
I did some fossicking around and putting some console.log entries about the place, and narrowed it down to how I had "fixed" these tests the last time I had issues with them. Previously the tests were running too quickly, and the Workshop listing had not been returned from the remote call in time for the test to try to submit the form, and any tests that relied on filling-out the form went splat cos there were not (yet) and workshops to select. OKOK, hang on this is what I'm talking about:
Those come from a remote call, so the data arrives asynchronously.
My fix was this bit in that test:
it("should disable the form and indicate data is processing when the form is submitted", () => {
component.vm.$watch("workshops", async () => {
await flushPromises();
//...
});
});
I was being "clever" and watching for when the workshops data finally arrived, waited for the options to populate, then we're good to run the test code. A whole bunch of the tests needed this. Now I hasten to add that I did thoroughly test this strategy when I updated all the tests. I made them all fail one of their expectations, watched the tests fail, then fixed the assertions and watched them pass. It's not like I made this change and just went "yeah that (will) work OK on my machine".
So what was the problem? Can you guess? Looking now, the tests do make a certain assumption.
Well. So my original issue was the code I was testing was running slow, so I changed the tests to wait for a change, and then run. And last week I tweaked my Docker settings to speed up all my containers. Now the code isn't slow. So now the workshops data is already loaded before the test code gets to that watch. So… there's nothing to watch. I started watching too late. I proved this to myself by slowing the remote call down again, and suddenly the tests started working again (ie: that test started to fail like I wanted it to).
It occurred to me then I had solved the original issue the wrong way. I was thinking synchronously about an asynchronous problem. I can't know if the data will arrive before or after my test runs. Just that at some time it is promised to arrive. Aha!
The data was already coming back in a promise (from WorkshopDAO.js):
selectAll() {
return this.client.get(this.config.workshopsUrl)
.then((response) => {
return response.data;
});
}
The problem is that by the time it bubbles back through DAO › Repository › Service › Component, I'd ditched the promise and just waited for the value (WorkshopRegistrationForm.vue):
async mounted() {
this.workshops = await this.workshopService.getWorkshops();
},
And I needed that this.workshops to just be the eventual array of objects, becauseI have a v-for looping over it. And v-for ain't clever enough to take the promise of an array, it needs the actual array (this is from the same file, just further up at line 82):
<option v-for="workshop in workshops" :value="workshop.id" :key="workshop.id">{{workshop.name}}</option>
I knew what I needed to do in the test. Instead of the watch, I just needed to append another then handler to the promise. Then whether or not the data has arrived back yet, the handler would run either straight away or once the data got there. But how do I get hold of that promise?
In the end I cheated: (again, same file, but a new version of it):
data() {
return {
//...
promisedWorkshops: null,
workshops: [],
//...
};
},
//...
async mounted() {
this.promisedWorkshops = this.workshopService.getWorkshops();
this.workshops = await this.promisedWorkshops;
},
I put the promise into the component's data as well as the values :-)
And the test becomes(from test/unit/workshopRegistration.spec again):
it("should disable the form and indicate data is processing when the form is submitted", async () => {
component.vm.$watch("workshops", async () => {
await component.vm.promisedWorkshops.then(async () => {
await component.vm.$nextTick();
As I said about I just slap all the code in a then handler instead of a watch callback. The rest of the code is the same. I need to wait that tick because the options don't render until the next Vue-tick after the data arrives.
That's a much more semantically-appropriate (and less hacky) way of addressing this issue. I'm reasonably pleased with that as a solution. For now.
Having learned my lesson I went back and retested everything in both a broken and working state, with an instant response time, and a very delayed response time on the remote call. The tests seem stable now.
Until I find the next thing wrong with them, anyhow.
OK that's enough staring at code on the screen for the day. I'm gonna stare at a game on the screen instead now.
Righto.
--
Adam
