Write test fixturing for libfetchers #363
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#363
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Steps:
Move the serveHTTP infrastructure from
static std::tuple<uint16_t, AutoCloseFD>
serveHTTP(std::vector<Reply> replies)
into a .cc file in libutil-support instead and add a header, then bring up a libfetchers unit test suite using the http server in a similar way as tests/unit/libstore/filetransfer.cc.
actually. can we do one better and include libmicrohttpd or something that's actually an http server?
serveHTTP
is already grown perhaps a bit too far, and testing actual fetchers might need a lot more still?yeah, we probably should just do that. i have also abused python http.server elsewhere as an http server that's already in our closure. microhttpd would also be extremely reasonable for the c++ side. i would be fine with either approach, either doing it in c++ or doing the fake apis in python.
stuff like https://gerrit.lix.systems/c/lix/+/1363 is just goofy and we would like to make it easier to get it right in the future