Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests required #52

Closed
kch opened this issue Sep 30, 2014 · 2 comments
Closed

Tests required #52

kch opened this issue Sep 30, 2014 · 2 comments
Milestone

Comments

@kch
Copy link
Contributor

kch commented Sep 30, 2014

rack-timeout is big and scary now, interacts with many ruby versions and multiple frameworks, and follows many different code paths depending on its various settings. That means we're in dire need of testing.

We got some good stuff from @chadbailey59 in the cb-appraisals branch, which I've synced with current master in the kch-testing-from-cb-appraisals branch. This is great because it tests with various frameworks/versions, but I find it a tad convoluted and involves a ton of dependencies ATM. Would love to find a way to trim it down.

We have a much simpler but also very good approach in #48 from @JackDanger, synced to current master in the kch-testing-from-jackdanger-patch branch. This only tests within rack itself, bypassing all the http and framework stuff. I like this for most testing, but in addition to that I want integration tests like chad's, or something even more external, maybe using libcurl and static test apps per framework.

So both are good starts but a lot more work is needed. After 0.1.0 is out (#38), this is our top priority.

@kch
Copy link
Contributor Author

kch commented Jan 19, 2015

I've come to lean against kch-testing-from-cb-appraisals as it involved adding a bunch of code to rack-timeout itself, and that reeks of unnecessary coupling.

kch-testing-from-jackdanger-patch also did some changes to rack-timeout, but reverting those and keeping just the spec works just fine. So that's a better way.

There's still the problem that rack-timeout can only be tested properly from the outside, by observing the resulting logs and http responses, and neither approach really goes for that.

@wuputah
Copy link
Collaborator

wuputah commented May 18, 2018

considering (minimally) resolved by #127. Further tests can be added from there.

@wuputah wuputah closed this as completed May 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants