Testing

[BaderBC]

We should try achieving near 100% test coverage.

For this purpose I would consider writing a mock API server (or use external solution, like this one ).

[Taran1508]

@BaderBC i would like to work on this!

[BaderBC]

Hi,
I'm glad to hear that.

Test coverage is something really important to us, because it would help with major updates.

Currently we need to decide which server we wanna setup for testing, whether to write simple server using e.g. python (which I think would be fine) or extarnal existing tool for such testing.
Please let me know if you have any suggestions.

Bigger problem is vulcan migration. Apparently there will be new version of vulcan (#74). We don't know yet if it would change API endpoints.
Please note that there's a chance, some of test which you will write, could potentially require major update in order to work with upcoming new vulcan version.

If you don't have problem with that, we'll wait for info about which technologies would you consider for testing API server and then, ater making our decision, you'll able to start your work 🙂

Thanks for your eagerness to contribute to our library!

[Taran1508]

Thank you, @BaderBC , for considering my request. I will respond to all your queries within 24 hours and give you the best possible suggestions and solutions I have.

[BaderBC]

Speaking of my previous idea to use Python, I've changed my mind. I think TypeScript would be a better choice for writing our own API server because it would allow us to share types between the tests and the actual codebase.

But that's just something that came to mind.

[Taran1508]

That sounds great! TypeScript would definitely help with type safety and sharing types. I'm comfortable with Typescript, JavaScript, Jest, Cypress and jsdom, so I'm ready to help with the mock API setup or integrate any external solutions you have in mind.

[BaderBC]

Ok, let me know if you find some other ideas to consider ;)

[Taran1508]

Will do! I'll let you know if anything else comes to mind. I'm excited to dive into this and explore different approaches. Also, please remember to assign this task to me when you're ready.

[Taran1508]

@BaderBC
How have you been doing?
Could you please update me about the task we discussed the other day?
As discussed, I want to continue with TypeScript in addition to JavaScript, Cypress, and Jest for the project. What are your thoughts on this, and do you have any additional suggestions? Also, please remember to assign this task to me when you're ready.

[BaderBC]

I'm glad you choose tech stack for testing. But we still need to write REST API server.

Our library is basically helper for REST API. We need to make clone of vulcan API working similar enough to test this library.

So the thing I want to know from you is how you're gonna implement that rest API.

Personally I would consider express.js + typescript + sqlite (id required)

Any thoughts or suggestions?

[BaderBC]

I made some research

We could consider also nest.js and koa.

Nest.js compared to express.js is more advanced and it's easier to maintain clear architecture, but it requires a lot of boilerplate and I thing it might be to complex solutiom to our problem.

Koa.js look promising. Even though I have no experience in it, koa reminds me of express.js but with more usefull features.

Summarizing - koa IMO looks promising but, because I have no experience with it, I cannot be sure if it's good idea.

[Taran1508]

Got it! I’m pretty comfortable with Express.js since I’ve done some projects with it, so I’m good to move forward with that.
But I’m also open to trying out Nest.js and Koa.js if they seem like a better fit. I can pick them up, learn them quickly , switch as needed. I’m leaning toward Express for now since it’s familiar and easy to work with, but I’m flexible and happy to adapt to Nest or Koa if we decide to go that way. What do you think?

[Taran1508]

My plan is to build the REST API using Express.js with TypeScript for type safety. I’ll keep things modular with clear routes and controllers, using SQLite to keep it lightweight. Additionally, I have a solid grip on routes and controllers from my previous demo project, #MovieTracker.
If we decide to go with Koa.js or Nest.js, I can easily switch things up. How does that sound?