Hey Kent! I've been thinking about something lately. I've worked at a number of different sass companies and something that is always an interesting problem is how we end-to-end test a software application that has a UI.

I love the idea of testing for confidence and, to that end, I've been wondering how we might begin to shift our thinking about confidence testing when we use some communication protocol, like GRPc or OpenAPI to and use those protocols to generate things like static types.

If a backend and frontend are both very well integration tested and the both use auto-generated types from the same spec file, how much e2e testing do we really need? It seems like the spec file would help bridge that confidence gap a lot for us.

I worked at a relatively large sass company once and we had about 300 e2e tests that ran on every PR. It took way too long, but we had a very high level of confidence when we shipped code. We had integration tests too, but I wonder as I reflect on that experience, should we have focused way more on integration tests and integration testing larger features of the software knowing that we had type safety from the communication protocols we used.

Really hoping to hear back from you! I respect your thoughts on testing a lot and I'm a long time consumer of your open source libraries and ideas.

Hey Kent! I've been thinking about something lately. I've worked at a number of different sass companies and something that is always an interesting problem is how we end-to-end test a software application that has a UI.

I love the idea of testing for confidence and, to that end, I've been wondering how we might begin to shift our thinking about confidence testing when we use some communication protocol, like GRPc or OpenAPI to and use those protocols to generate things like static types.

If a backend and frontend are both very well integration tested and the both use auto-generated types from the same spec file, how much e2e testing do we really need? It seems like the spec file would help bridge that confidence gap a lot for us.

I worked at a relatively large sass company once and we had about 300 e2e tests that ran on every PR. It took way too long, but we had a very high level of confidence when we shipped code. We had integration tests too, but I wonder as I reflect on that experience, should we have focused way more on integration tests and integration testing larger features of the software knowing that we had type safety from the communication protocols we used.

Really hoping to hear back from you! I respect your thoughts on testing a lot and I'm a long time consumer of your open source libraries and ideas.

Hey Kent! I've been thinking about something lately. I've worked at a number of different sass companies and something that is always an interesting problem is how we end-to-end test a software application that has a UI.

I love the idea of testing for confidence and, to that end, I've been wondering how we might begin to shift our thinking about confidence testing when we use some communication protocol, like GRPc or OpenAPI to and use those protocols to generate things like static types.

If a backend and frontend are both very well integration tested and the both use auto-generated types from the same spec file, how much e2e testing do we really need? It seems like the spec file would help bridge that confidence gap a lot for us.

I worked at a relatively large sass company once and we had about 300 e2e tests that ran on every PR. It took way too long, but we had a very high level of confidence when we shipped code. We had integration tests too, but I wonder as I reflect on that experience, should we have focused way more on integration tests and integration testing larger features of the software knowing that we had type safety from the communication protocols we used.

Really hoping to hear back from you! I respect your thoughts on testing a lot and I'm a long time consumer of your open source libraries and ideas.

Hey Kent! I've been thinking about something lately. I've worked at a number of different sass companies and something that is always an interesting problem is how we end-to-end test a software application that has a UI.

I love the idea of testing for confidence and, to that end, I've been wondering how we might begin to shift our thinking about confidence testing when we use some communication protocol, like GRPc or OpenAPI to and use those protocols to generate things like static types.

If a backend and frontend are both very well integration tested and the both use auto-generated types from the same spec file, how much e2e testing do we really need? It seems like the spec file would help bridge that confidence gap a lot for us.

I worked at a relatively large sass company once and we had about 300 e2e tests that ran on every PR. It took way too long, but we had a very high level of confidence when we shipped code. We had integration tests too, but I wonder as I reflect on that experience, should we have focused way more on integration tests and integration testing larger features of the software knowing that we had type safety from the communication protocols we used.

Really hoping to hear back from you! I respect your thoughts on testing a lot and I'm a long time consumer of your open source libraries and ideas.

Hey Kent! I've been thinking about something lately. I've worked at a number of different sass companies and something that is always an interesting problem is how we end-to-end test a software application that has a UI.

I love the idea of testing for confidence and, to that end, I've been wondering how we might begin to shift our thinking about confidence testing when we use some communication protocol, like GRPc or OpenAPI to and use those protocols to generate things like static types.

If a backend and frontend are both very well integration tested and the both use auto-generated types from the same spec file, how much e2e testing do we really need? It seems like the spec file would help bridge that confidence gap a lot for us.

I worked at a relatively large sass company once and we had about 300 e2e tests that ran on every PR. It took way too long, but we had a very high level of confidence when we shipped code. We had integration tests too, but I wonder as I reflect on that experience, should we have focused way more on integration tests and integration testing larger features of the software knowing that we had type safety from the communication protocols we used.

Really hoping to hear back from you! I respect your thoughts on testing a lot and I'm a long time consumer of your open source libraries and ideas.