search

kubernetes / dashboard

General-purpose web UI for Kubernetes clusters
Apache License 2.0
14.26k stars 4.14k forks source link

Automated testing #7504

Open eddiejaoude opened 1 year ago

eddiejaoude commented 1 year ago

What would you like to be added?

Currently there are only a couple of e2e tests, it would be good to get more code coverage for the projects functionality.

Initial discussion started here https://github.com/kubernetes/dashboard/issues/7205

Q. Playwright is a good alternative to Cypress with some really great features I like the feature that NASA used from Playwright that allows us to write a skeleton test with the function fixme, so others can get involved in the project.

Why is this needed?

This would reduce regression and also give confidence for new features and refactoring etc

maciaszczykm commented 1 year ago

I don't have any opinion on Playwright, I'm familiar with Cypress and it works pretty nice. If you would be able to support your idea with specific improvements that we would get with Playwright then we can talk about adding it.

I like the feature that NASA used from Playwright that allows us to write a skeleton test with the function fixme, so others can get involved in the project.

This doesn't seem to be very important at this stage. Since we don't have enough tests anything would be helpful at this point, so no need to create skeleton.

floreks commented 1 year ago

We are still in the process of moving to the GraphQL API. I don't think this is a good idea to start creating e2e tests at this point.

eddiejaoude commented 1 year ago

don't have any opinion on Playwright, I'm familiar with Cypress and it works pretty nice. If you would be able to support your idea with specific improvements that we would get with Playwright then we can talk about adding it.

There are other modern features that are beneficial, I can list these out, but I don't think a 1-1 comparison is needed, happy to stay with Cypress, the important part is to get test coverage to give confidence features/bugs etc can be done and nothing breaks.

This doesn't seem to be very important at this stage. Since we don't have enough tests anything would be helpful at this point, so no need to create skeleton.

Tbh this would the best time, because there are not many existing tests, we can add skeleton tests (the titles) and then we can get the community to help write the tests

eddiejaoude commented 1 year ago

We are still in the process of moving to the GraphQL API. I don't think this is a good idea to start creating e2e tests at this point.

Great, good to know there is still refactoring going on, because this is the perfect time to write tests, therefore after the refactor the developers can be confidence everything still works as planned 🎉

floreks commented 1 year ago

We are still in the process of moving to the GraphQL API. I don't think this is a good idea to start creating e2e tests at this point.

Great, good to know there is still refactoring going on, because this is the perfect time to write tests, therefore after the refactor the developers can be confidence everything still works as planned 🎉

Not really, since I am pretty certain that the refactoring will bring some breaking changes to the frontend. Tests could be written in parallel to our changes but definitely not before we even start.

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale