Skip to content

What I learned along the way

Ricardo Fearing edited this page Dec 9, 2021 · 5 revisions

Lessons Learned in making JS Data Structures

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. 😄

Methodology:

Lesson: Keep private things private

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.

Lesson: Utilize assert

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

Testing

Lesson: Ensure tests are in a test directory, or that the build script ignores .test.ts files

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

Lesson: Break up your tests.

  • I had originally had a longer list of expect statements nested in tests (same as it).
  • 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 that test will run, which can lead to testing "wack-a-mole"
  • You can also utilize beforeEach and afterEach for setup and teardown for each test.