Talks
Speakers
Events
Topics
Search
Sign in
Search
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
search talks for
⏎
Suggest modification to this talk
Title
Description
Good integration tests are hard. There are many approaches for testing server/client HTTP libraries - all with various tradeoffs and problems that come up. Some are obvious, some are a little more tricky. I'll run through some approaches and problems I've come across developing server/client APIs, while developing these in a highly distributed systems setup at Engine Yard. Help us caption & translate this video! http://amara.org/v/FGat/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
The presentation titled "Testing HTTP APIs in Ruby" by Shai Rosenfeld at Rails Conf 2013 discusses the challenges and methodologies associated with testing server/client HTTP APIs, particularly in a distributed systems environment like those at Engine Yard. The speaker emphasizes the significance of APIs in modern software development, akin to the importance of websites in the late 1990s. ### Key Points Discussed: - **The Importance of APIs**: The importance of having an API for products in the current software landscape is compared to the essential nature of websites in the past. - **Testing Methodologies**: Rosenfeld outlines various approaches for testing APIs, such as: - **Isolated Testing**: Testing server and client independently, which does not guarantee integration compatibility. - **Sandbox Approach**: Enables running tests against a real server setup but may introduce complications like longer test run times and conflicts due to shared data. - **Fake Servers**: Proposing a fake server that mimics the real API externally, allowing fast, low-dependency local development. - **Cistern Framework**: Introduced as a client API framework for hard coding mock responses, facilitating effective local testing while ensuring consistency with the actual API responses. - **Shared Codebase for Mocks and Real API**: A methodology to unify both the fake and real API functionalities and reduce redundancy in code management. ### Illustrative Examples: - A fictional scenario involving a music labeling company where the speaker illustrates the roles of different developers and how they interact with the API through a client library. - Practical implications of each testing strategy were highlighted by detailing pros and cons, with specific emphasis on the real-world impact of each methodology in a development workflow. ### Conclusions and Takeaways: - Testing APIs is inherently complex, and there is no one-size-fits-all solution; each approach has its own trade-offs. - Validated mocks can greatly enhance confidence in both client and server interactions, thus improving development efficiency. - The evolution of the testing methodologies shared aims to harmonize the needs of the client and server developers while ensuring robust API functionality and user experience.
Suggest modifications
Cancel
