In this week for OSD700, we had our 2.6.0 release for Telescope. As what seems to becoming a pattern for all release weeks, many PRs are getting merged, and things are moving quickly. There was a lot of new things popping up, like Turborepo and Supabase, and I wish I had some time to get to know them better.
For me, my focus this week was to get to creating tests for Search, specifically advanced search. Unfortunately, it didn't go as smoothly as I had hoped for. But, there was progress, and ElasticSearch-mock and I seem to be gradually getting along.
ElasticSearch Mock
If there was a type of friend that ElasticSearch Mock (ES Mock) would be, it'd probably be one of those that you seem to know them, but actually don't. They're picky and stubborn, and like to give you surprises and tease you to no end. This about sums up the relationship I've had with ES Mock this week. Every time I thought I might've have had a breakthrough and could move on, it seems to drag me back while yelling, "No! Play with me more!", and then comes up with more hurdles that I'll need to jump through.
Getting ES Mock exported from Satellite
"But, Roxanne" you say, "The article says clearly, Smooth mocking."
Under normal circumstances, it might be smooth. ES mock is a library provided by Elastic.co, who are the ones that created the regular ElasticSearch. How I understand that they have it set up is that during mocking, a mocked API would establish a connection that an ES client could connect to instead of using the regular connection.
Except Telescope is a little special. Thanks to my PR last week, Telescope doesn't use ElasticSearch directly anymore, and instead uses a client packaged inside of Satellite. So, in order to get this special client mocked in our tests, Satellite will also need give us access to its mock.
There were a lot of experiments, a couple versions, and many tweaks. In between I realized just how picky and strict ES mock could get with the APIs. Here is an example from the ES Mock npm registry README
mock.add({
method: 'GET',
path: '/_cat/health'
querystring: { pretty: 'true' }
}, () => {
return { status: 'ok' }
})
client.cat.health(console.log) // => 404 error
client.cat.health({ pretty: true }, console.log) // => { status: 'ok' }
Basically, the more field that are specified, the stricter the mock gets. There are some fields that if they exist in the API, you had to specify in the query, and vice versa, otherwise, ES Mock would just think the right mock doesn't exist, and return a 404 Mock not Found error.
At last, a final version was merged into Satellite. Prof helped a lot with this final version, and it was fascinating to see him code. There was a few coding tricks that I wasn't aware of. Especially the line
client.mock = mock
Now, we could not only get a client instance, we can also get a mock object { mock } as well. I'm just fascinated cause I think the original way I had it in my head wouldn't be as condensed.
ES Mock Strikes Again
Finally, with the changes in Satellite released, and updated in the Search service, it seemed that maybe, just maybe it would be smooth sailing onward, and I could finally get to really mocking Search. But nope, this time around, the mocks weren't clearing for me and was messing with my tests. This got me a little frustrated, cause it was clearing for the tests written for Satellite.
At this point, last night of writing this blog, I decided I needed a break from playing with ES Mock. It was getting to a point where, even taking a small nap, I'm dreaming of coding and just getting the Mock not Found error. A break might be working cause as I am writing this blog, I'm forming some theories that I'd like to test out to make it right. Hopefully I'll get to write about this next week.
Conclusion
It doesn't seem like I got much accomplished this week, but I'd say I tried. I had spent a lot of time on OSD this week, and I wish I had more, or that I was smarter so my time could be more efficient. Like I mentioned, I would really like to have the time to explore more of what's going on in Telescope, and branch off and maybe do reviews in other areas.
It's lucky that most of the meetings during off hours are recorded (a little sad about the lost Supabase meeting), and that there's lots of information in the weekly blogs to read about (Supabase meeting blog please? *Wink *Wink).
I'm also lucky that, since its the start of the semester, my other courses are rather light. I shudder to think what would happen later on when things pick up. Regardless, OSD doesn't seem like coursework. Things are much more dynamic, and I'm pretty sure the more time that I put into it, the more I'd gain.
Oldest comments (0)