thunderstrike/purescript-httpurple
thunderstrike/purescript-httpurple
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c208dffb7b
purescript-httpurple/test/Test/HTTPure/PathSpec.purs

41 lines
1.4 KiB
Haskell
Raw Normal View History

Clean up tests and examples (#86)
2017-10-26 21:19:30 +00:00
module Test.HTTPure.PathSpec where
Refactor to take advantage of pattern matching as routing mechanism (#24)
2017-07-14 06:28:57 +00:00
Don't import prelude so explicitly (#37)
2017-07-18 05:31:46 +00:00
import Prelude
Refactor to take advantage of pattern matching as routing mechanism (#24)
2017-07-14 06:28:57 +00:00
import Test.Spec as Spec
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
import HTTPure.Path as Path
Clean up tests and examples (#86)
2017-10-26 21:19:30 +00:00
import Test.HTTPure.TestHelpers as TestHelpers
import Test.HTTPure.TestHelpers ((?=))
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
Clean up tests and examples (#86)
2017-10-26 21:19:30 +00:00
readSpec :: TestHelpers.Test
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
readSpec = Spec.describe "read" do
Spec.describe "with a query string" do
Spec.it "is just the path" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "test/path?blabla" "" []
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
Path.read request ?= [ "test", "path" ]
Spec.describe "with no query string" do
Spec.it "is the path" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "test/path" "" []
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
Path.read request ?= [ "test", "path" ]
Spec.describe "with no segments" do
Spec.it "is an empty array" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "" "" []
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
Path.read request ?= []
Spec.describe "with empty segments" do
Spec.it "strips the empty segments" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "//test//path///?query" "" []
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
Path.read request ?= [ "test", "path" ]
Query param fixes (#128) * Represent emtpy query parameters as empty strings instead of "true" * Encode and decode query params Fixes #126 * Pass invalid query parameters through instead of ignoring them * Decode the plus sign `+` as a space ` ` in query string * Decode percent encoding in path segments * Update History.md
2018-11-06 17:45:37 +00:00
Spec.describe "with percent encoded segments" do
Spec.it "decodes percent encoding" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "/test%20path/%2Fthis" "" []
Query param fixes (#128) * Represent emtpy query parameters as empty strings instead of "true" * Encode and decode query params Fixes #126 * Pass invalid query parameters through instead of ignoring them * Decode the plus sign `+` as a space ` ` in query string * Decode percent encoding in path segments * Update History.md
2018-11-06 17:45:37 +00:00
Path.read request ?= [ "test path", "/this" ]
Spec.it "does not decode a plus sign" do
Add HTTP version (#137) * v0.8.1 * Add the HTTP version to `Request` The `node-http` `Request` has the HTTP version on it. We can make it available in our `Request` for consumers. We went the naive approach first and typed it as a string. There is some structure to the version, so we could attempt to parse it. It's unclear what we would do if parsing failed though. Maybe we want something like: ```PureScript data Version = Known { major :: Int, minor :: Int } | Unknown String ``` That would allow us to parse the known format, and fallback to accepting anything else. It's definitely something to discuss anyway. * Make HTTP version its own data type There are only a handful of HTTP versions that are commonly used. We can talk about those explicitly and fallback to any arbitrary version. The changes here try to follow the patterns elsewhere in the code base. Hopefully, it's not too far off.
2019-04-25 17:13:04 +00:00
request <- TestHelpers.mockRequest "" "GET" "/test+path/this" "" []
Query param fixes (#128) * Represent emtpy query parameters as empty strings instead of "true" * Encode and decode query params Fixes #126 * Pass invalid query parameters through instead of ignoring them * Decode the plus sign `+` as a space ` ` in query string * Decode percent encoding in path segments * Update History.md
2018-11-06 17:45:37 +00:00
Path.read request ?= [ "test+path", "this" ]
Refactor to take advantage of pattern matching as routing mechanism (#24)
2017-07-14 06:28:57 +00:00
Clean up tests and examples (#86)
2017-10-26 21:19:30 +00:00
pathSpec :: TestHelpers.Test
Refactor to take advantage of pattern matching as routing mechanism (#24)
2017-07-14 06:28:57 +00:00
pathSpec = Spec.describe "Path" do
Improve and simplify APIs (#68)
2017-09-26 06:08:07 +00:00
readSpec
Reference in New Issue Copy Permalink