-
Notifications
You must be signed in to change notification settings - Fork 0
What I learned along the way
As I develop and create this repository, I'd like to share what I've learned along the way. Rather than creating a new /docs
directory or /things-learned.md
file, I decided to utilize GitHub's wiki. As I learn things, as best as I can, I'll put them here 👨🏼💻. It could be beneficial to future me, or to anyone who comes across it. 😄
In building the SinglyLinkedList
class, I had head
and tail
exposed and was returning my entire Node with my getters. This opens the class up to abuse and I should think of anything as public as part of the spec and that it's going to be used, whether I intend for it to or not.
- One option, to that effect is to utilize JavaScript's #private class feature
- Since we're already utilizing TypeScript, I utilized its private access modifier
I had been using optional chaining in my SinglyLinkedList
class due to TypeScript complaining Object is possibly 'null'
on any use of SinglyLinkedNode
instance methods. This was caused by my constructor's setting head
and tail
to null
. The problem tho, was, I could guarantee by that point in the code that the methods did exist (and they they were not null
) I learned about and utilized assert
so that I could continue in my code with confidence and remove the optional chaining. Big thank you to Gary
In making the SinglyLinkedList
class I was having trouble getting some tests to pass. I couldn't figure out what was going on, when I noticed I had 11 files changed but had only edited three.
I realized my prepare
script was building and my regex was building my tests too. I could update the regex to ignore .test.ts
files, but for the time being, moved the tests from inside their classes' respective directory into a /tests
directory, to avoid build built into the /lib
folder. Visually, I changed
From To /src - SinglyLinkedList - SinglyLinkedList.test.ts - ... /tests - SinglyLinkedList.test.ts
- I had originally had a longer list of
expect
statements nested intests
(same asit
). - Instead an argument can be made to break up your tests into groups that describe a single functionality. If one
expect
fails, none of the rest in thattest
will run, which can lead to testing "wack-a-mole" - You can also utilize
beforeEach
andafterEach
for setup and teardown for each test.