search

hasadna / open-bus-map-search

open-bus-map-search
https://open-bus-map-search.hasadna.org.il/dashboard
MIT License
50 stars 88 forks source link

add unit tests #107

Open shootermv opened 11 months ago

shootermv commented 11 months ago

things to test:

amabelleS commented 11 months ago

Hey:) I don't have much experience with testing, little with jest, some with cypress. That is why I would love to take this issue. Are there videos Noam posted somewhere on how to do unit tests and e2e?

shootermv commented 11 months ago

Noad did very good guide about e2e palywright tests here https://www.youtube.com/watch?v=jEWG7nYKk_0 for creating unit tests for components, i think you better look at react testing library docs https://testing-library.com/docs/react-testing-library/intro

On Wed, Oct 11, 2023 at 9:50 PM Amabelle Trachtenberg < @.***> wrote:

Hey:) I don't have much experience with testing, little with jest, some with cypress. That is why I would love to take this issue. Are there videos Noam posted somewhere on how to do unit tests and e2e?

— Reply to this email directly, view it on GitHub https://github.com/hasadna/open-bus-map-search/issues/107#issuecomment-1758307578, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKGMHUUMEEW3Y3KZ7R5EADX63S6DANCNFSM6AAAAAA52NLXSY . You are receiving this because you authored the thread.Message ID: @.***>

-- http://gs500coder.blogspot.com

amabelleS commented 11 months ago

Noad did very good guide about e2e palywright tests here https://www.youtube.com/watch?v=jEWG7nYKk_0 for creating unit tests for components, i think you better look at react testing library docs https://testing-library.com/docs/react-testing-library/intro … On Wed, Oct 11, 2023 at 9:50 PM Amabelle Trachtenberg < @.> wrote: Hey:) I don't have much experience with testing, little with jest, some with cypress. That is why I would love to take this issue. Are there videos Noam posted somewhere on how to do unit tests and e2e? — Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKGMHUUMEEW3Y3KZ7R5EADX63S6DANCNFSM6AAAAAA52NLXSY . You are receiving this because you authored the thread.Message ID: @.> -- http://gs500coder.blogspot.com

Thx for the links:) I'll look into them. You can assign it to me if you like.

NoamGaash commented 11 months ago

@amabelleS what kind of tests will you do? e2e/unit/component? I'll create a separate issue

knightcube commented 11 months ago

@shootermv @NoamGaash I would like to get started working on adding Unit Tests (with Jest) too. I don't have much experience with writing Unit tests. So I guess this project could be a great starting point.

amabelleS commented 11 months ago

@amabelleS what kind of tests will you do? e2e/unit/component? I'll create a separate issue

all kinds:) we'll start with e2e - #118 :)

NoamGaash commented 11 months ago

sounds perfect! thank you both let me know how I can help @knightcube @amabelleS

knightcube commented 11 months ago

@NoamGaash By the way, I am looking for a code coverage tool that can generate code reports. It will help us measure code coverage for our project.

After a bit of debugging, I got to know that we can't use Playwright to create code coverage reports yet. Here is another tool that is helpful to some extent - https://github.com/anishkny/playwright-test-coverage

But I couldn't get it working for our project and hence raised this issue - https://github.com/anishkny/playwright-test-coverage/issues/148

If we used Vitest, it would have been simpler to generate code coverage reports but with Playwright, I guess we just have to wait a bit (sigh!).

Also what if we migrate to Mocha as our testing library instead of Playwright?

Here is a detailed comparison between Mocha and Playwright - https://knapsackpro.com/testing_frameworks/difference_between/mochajs/vs/playwright

NoamGaash commented 11 months ago

In my opinion, code coverage is a bad metric - the fact every line in the code executed at least once during your test suite has nothing to do with finding bugs and regressions. Maybe it's good for upper management in some companies, where a rough estimation of "code quality" is required from the RND department, but having 100% code coverage is not something we should be looking forward.

I do consider adding visual tests. as Applitools employee, I think we have an open source plan. I'll check that out.

Anyway, the main focus (in my opinion) should be on preventing regression, and reducing the fear factor. When I review a pull request, I usually won't run it locally at all. I expect the test suit to test the buisiness logic of the application.

For example, I don't think anyone would break the ordering of menu items. If someone will try to change that, it will be very easy to tell that from the code, and reject their contribution. However, if someone will break one of the maps, and it won't longer contain any bus icons, it would be infeasible to know without cloning their branch, executing the code and manually go over each page of the application.

Therefore, testing the existence of bus icon in every page would provide us more value.

That's my opinion. What do you think?

knightcube commented 11 months ago

I strongly appreciate your detailed response. Thanks a bunch!

I agree with your point about the ordering of the menu items.

I would like to work on a better test scenario.

Could you please assign (or create) an issue which I can write tests for?

Happy to work on Unit Tests, Integration tests, or e2e Tests.