You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 currentmaster
in thekch-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.
The text was updated successfully, but these errors were encountered: