vulcan-api / vulcan-api-js

Unoffical Vulcan UONET+ SDK for JavaScript / TypeScript
https://vulcan-api.github.io/vulcan-api-js/
MIT License
27 stars 1 forks source link

Testing #73

Open BaderBC opened 3 months ago

BaderBC commented 3 months ago

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 commented 3 months ago

@BaderBC i would like to work on this!

BaderBC commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

Taran1508 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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?

BaderBC commented 3 months ago

@Taran1508 Sound great, but I would really consider chosing koa over express. Koa look promising while being really similar to express.

Please check out koa and give me info, what do you think about it.

I will read some docs later and together we should be able to decide between express and koa.

Thank for your time, Have a nice day!

Taran1508 commented 3 months ago

Koa does look promising and pretty similar to Express. After looking into it, I think both frameworks are solid choices. I’m comfortable with either, so I’m good to go with whichever you prefer. Additionally, since we only need to mock an API server, I suggest going with plain JavaScript instead of TypeScript. TypeScript can add complexity, and we’d end up building the same code again in JavaScript. Plus, JavaScript supports JEST, which is a great and popular library for testing our mock API server.

BaderBC commented 3 months ago

After consideration of both of them I think express would be better because it's quite simmilar and more popular.

You can start your work, try to read our library code and understand how it works.

Your first task will be to write REST API server which will imitate vulcan API. We wanna do it because vulcan is closed source and also we cannot send real api calls for testing purposes. Btw vulcan is electronic school diary. Use express + Typescript + SQLite (if sql is needed)

Please keep in mind that ONLY purpose for that server will be testing this library. It means that concepts like e.g. seeding might be useful for you.

I checked out your GitHub and I see you're from India. As far as I know vulcan is only available in Poland, which means the only way for you to make it's clone is reading how we currently interact with vulcan api in lib or you can ask somebody from our team to give you example vulcan api call reponse.

Personally I don't have a lot of experience with vulcan API if you have any questions I think @maxidragon will be the one who can help you.

I heard that @cooligus and @sewe2000 have alse some experience.

Now I will assign this task to you. Feel free to ask questions. You can start your work. Good luck!

BaderBC commented 3 months ago

@Taran1508

There was once a project called Wulkanowy - 3rd party app for vulcan e-diary. It was recently closed. I just saw that they have made a fakelog server, which is exactly what I wanted you to write in express.

So maybe instead of writing it from beginning we would just fork this repository and use it for testing purposes. It would save you a lot of work.

What do you think? Btw it is written in pure JS, so we could later, after finishing this issue, think about rewriting it into TS.

BaderBC commented 3 months ago

You know what, I made my mind, here's our fork: https://github.com/vulcan-api/fake-log .

Try running it and writing e2e and integration tests now. If you encounter any problems, let me know.

Taran1508 commented 3 months ago

@BaderBC Thanks for the fake log! So there's no need of writing a mock API!

I'll start running it and writing tests you mentioned. And I'll let you know if I encounter any problems! Is it okay to start this work after 4 hours from now? Because we have different time zones and am currently at my college right now.

BaderBC commented 3 months ago

Don't need to rush. Actually in my country my team still has a summer break (being precise we have last week of it) and we'll start working on this lib after it ends.

In other words - even that this issue is important to us, you have plenty of time.

Have a nice day!