Automated Tests in Typescript

Today I wrote my first automated tests for my TypeScript learning project.

Until now, most of my testing was manual: run the code, check the output, adjust, repeat.

That works for small experiments, but today I started seeing why automated tests matter once business rules begin to grow.

The most useful lesson was not just the syntax of describe, it, and expect.

The useful lesson was this:

Tests expose unclear thinking.

Some examples from today:

• a function called getOpenJobs was too vague, so it became getSavedJobs
• a project function sounded like "ready to start", but the actual rule meant "overdue to start"
• id lookups were returning arrays, but a unique id lookup should return one item or undefined
• TypeScript caught union type mistakes that the runtime tests would not catch

So the tests were not only checking behavior.
They were pushing the model to become clearer.

I also learned a practical distinction:

Manual testing asks:
"Does this work right now?"

Automated testing asks:
"Will I know when this breaks later?"

Next step: testing async repository behavior before moving toward a real database.