search

cypress-io / full-network-proxy

Demo repo for Cypress with full network stubbing support
https://github.com/cypress-io/cypress/pull/1931
5 stars 1 forks source link

Move this to recipes or to driver tests #5

Open brian-mann opened 6 years ago

brian-mann commented 6 years ago

I get where you're going with this repo, but it's really just a bunch of recipes that could be part of cypress-example-recipes. In that repo we have many examples with their own README, and this could be part of the overall group instead of being orphaned by itself and needing its own CI setup, etc.

I would still prefer these be driver tests in cypress repo which would be much easier to comment on, review, and be "connected" to the new code. As it stands I have to look here to understand what your new API ideas are.

bahmutov commented 6 years ago

And once the network stubbing is done I can move the examples into recipes and driver tests. Work in progress does not have to affect the existing recipes

Sent from my iPhone

On Jun 12, 2018, at 22:31, Brian Mann notifications@github.com wrote:

I get where you're going with this repo, but it's really just a bunch of recipes that could be part of cypress-example-recipes. In that repo we have many examples with their own README, but could be part of the overall group instead of being orphaned by itself and needing its own CI setup, etc.

I would still prefer these be driver tests in cypress repo which would be much easier to comment on, review, and be "connected" to the new code. As it stands I have to look here to understand what your new API ideas are.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

brian-mann commented 6 years ago

Sure I get the done part for the recipes - but as you iterate on the API signatures of cy.route and cy.server there will be a PR that is solely implementation in cypress and we'll have to look at a separate repo for the actual test code that expresses it. It's a bit weird... is there any upside to having a separate experimental repo that won't be part of the PR?

No matter what you'll need to either rework or refactor (or delete) all of the existing tests in the driver, and at the very least going through them will help you account for all of the existing ways the API works.

bahmutov commented 6 years ago

Because all or almost all current driver tests will fail due to api changes and new capabilities. Boom, a lot of work to fix, and the users still cannot see what capabilities are going to be available. Also, wouldn’t the tests be better in kitchen sink rather than recipes

Sent from my iPhone

On Jun 12, 2018, at 22:38, Brian Mann notifications@github.com wrote:

Sure I get the done part for the recipes - but as you iterate on the API signatures of cy.route and cy.server there will be a PR that is solely implementation in cypress and we'll have to look at a separate repo for the actual test code that expresses it. It's a bit weird... is there any upside to having a separate experimental repo that won't be part of the PR?

No matter what you'll need to either rework or refactor (or delete) all of the existing tests in the driver, and at the very least going through them will help you account for all of the existing ways the API works.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

brian-mann commented 6 years ago

The kitchen sink is a great place for an overview of what the API's can do - but it cannot require a server so it's fairly limited for showing off the network stubbing layer.

With that said - yes definitely a few kitchen sink tests are necessary, but the true power and all the different ways to utilize and express the network layer is better suited for a recipe (which is an actual app) that fully flexes those muscles.

I get what you mean about the driver tests, but those will have to be fixed at some point anyway. I guess its nice to imagine users "seeing" what new capabilities there are going to be, but the traffic differences between this repo and the main repo are 1000:1. Adding these examples in a PR would actually enable people to see the new stuff coming out - the change delta to the existing API's and the implementation details to comment on. It's really just about better visibility, not less visibility.

There are so many users commenting and have been excited about the new network layer API's that pointing them to a PR would instantly quench that thirst.

Who is currently going to come here (let alone find out about this repo), look at what's going on and then synchronize that work with a separate PR in a separate branch in a separate repo? Just don't see any upside to that at all.