Artwork

コンテンツは Kent C. Dodds によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Kent C. Dodds またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal
Player FM -ポッドキャストアプリ
Player FMアプリでオフラインにしPlayer FMう!

Do generated types from OpenAPI spec change testing?

6:50
 
シェア
 

Manage episode 415317275 series 2982717
コンテンツは Kent C. Dodds によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Kent C. Dodds またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal

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.

Do generated types from OpenAPI spec change testing?
  continue reading

199 つのエピソード

Artwork
iconシェア
 
Manage episode 415317275 series 2982717
コンテンツは Kent C. Dodds によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Kent C. Dodds またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal

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.

Do generated types from OpenAPI spec change testing?
  continue reading

199 つのエピソード

すべてのエピソード

×
 
Loading …

プレーヤーFMへようこそ!

Player FMは今からすぐに楽しめるために高品質のポッドキャストをウェブでスキャンしています。 これは最高のポッドキャストアプリで、Android、iPhone、そしてWebで動作します。 全ての端末で購読を同期するためにサインアップしてください。

 

クイックリファレンスガイド