Time Spent: ~1 day across a week. I took my time with this assignment.
Where Time Was Spent: For my configuration, I had to make some adjustments to my tsconfig and my package.json to work with my Windows device. For tsconfig, I had to change "module" to Node16, which didn't cause anything to break. I had to install cross-env and use it in front of my test script, as well as install the jest-jasmine2 test runner to run the tests. Figuring out TypeScript types took up a lot more time than I would have liked, but it also helped me be more careful with handling queries to my database compared to working with JavaScript. Designing my API is also something I took my time with. I'm still new with learning development and wanted to research and plan out developing a REST API. This assignment was perfect, since I learn by doing, and it prompted me to ask questions such as when a 400 or a 404 error is more appropriate to use, how to stick to conventions, etc. Writing tests also took time, but this was mainly because I wanted to make sure I didn't overtest, and that I also test the more complex request combinations for my back-end. I also had to take time setting up my takedown function that regenerates the database for the tests. I didn't realize that leaving my inserts uncommented in the setup.sql file causes this error where the first test case will fail on the first test run after I run npm run setup, but pass whenever I try to run npm run test again. Debugging my request handlers took time because of figuring out TypeScript types and using zod. Setting up the schemas for year inputs that I use was complicated because some of my tests would produce too many errors. I use a filter where you can get books published between a minimum and maximun year, so setting up zod to make sure that the maximum year is not less than the minimun year, while also validating that both inputs are numerical, took some time to debug.
TypeScript helped me control how my server responded to requests. I was able to ensure that JSON objects with the required properties were included in responses, that I wouldn't enclose my data in an unneccessary array/JSON object by accident, etc. I was able to improve my coverage with testing with some of the errors I got. For example, I use the length property of arrays to help verify queries from my database, but TypeScript would hate this if I didn't explicitly make sure my query's response wasn't a type with a length property. I like that TypeScript helps expose possible errors that I don't intuitively think of. I also realized that I needed tests to ensure users didn't input empty strings for text inputs because of TypeScript. I like that it makes it less likely for me to miss the simpler tests, even though typing can be a pain.
I mainly set up interfaces and types to help me set types. I'm more concerned that I didn't do enough typing, and that there's a hidden any type somewhere in my code. I'm hoping to develop confidence with this. I also am trying to differentiate when it's important to use interface over type and vice versa, but I think my implementation is appropriate.
Testing was the best part of this. It was satisfying testing my work, since at this point I debugged most of the handler code. It helped me make any final adjustments to my code, as well as consider how my handlers would be used/interact with each other. It helped give me direction to my development process, since it served as a guiding tool for what areas still needed work and how.
Testing did not help me find many bugs. It helped me consider functionality adjustments, like filters and when to use route parameters vs. query strings.
Since I wrote all my tests at the end of development, I would change this to instead write tests as I write my handlers to see what the difference would be. That could help me more in the future. I would say I didn't learn much from testing, and that the main benefit was that it provided a sense of much needed structure to an open-ended project.