Conversation
| protocol Auth: Sendable { | ||
| func start() async throws -> URL | ||
| func waitForToken() async throws -> String | ||
| } |
There was a problem hiding this comment.
This represents the local auth server we start up and ask for a token. There's an in-memory version below that can just immediately give back the callback URL and token when asked. We should beef it up to allow emitting errors too and get test coverage on that, but we can do that later.
| import Foundation | ||
| import ZIPFoundation | ||
|
|
||
| protocol FileSystem: Sendable { |
There was a problem hiding this comment.
This is an abstraction of a file system held in memory. We've used this kind of dependency quite a bit in the past, but for this I needed to beef it up quite a bit since pfw does a lot more with the file system (unzips, creates directories, etc.).
| import Foundation | ||
| import XCTestDynamicOverlay | ||
|
|
||
| protocol OpenInBrowser: Sendable { |
There was a problem hiding this comment.
Just a simple interface to opening the browser to a specific URL.
| protocol PointFreeServer: Sendable { | ||
| func downloadSkills(token: String, machine: UUID, whoami: String) async throws -> Data | ||
| } |
There was a problem hiding this comment.
An interface to abstract away downloading skills from our Point-Free server.
| func validate() throws { | ||
| guard (tool != nil) != (path != nil) else { | ||
| throw ValidationError("Provide either --tool or --path.") | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
We now require either tool or path be provided.
| @testable import pfw | ||
|
|
||
| nonisolated(nonsending) | ||
| func assertCommand( |
There was a problem hiding this comment.
Added an inline snapshot testing tool for testing CLI commands. It's rough right now, but I think there are some interesting directions we can take it.
| } | ||
|
|
||
| // TODO: Explore a dependency alternative to this. | ||
| func withCapturedStdout(_ body: () async throws -> Void) async rethrows -> String { |
There was a problem hiding this comment.
This captures stdout, which is cool, but also means we can't run tests in parallel because we will get interleaving logs from other tests. An alternative would be to put printing behind a dependency but then that means you have to know to use the dependency instead of print.
| - name: Test | ||
| run: swift test |
There was a problem hiding this comment.
Let's start running tests in CI.
I couldn't get Linux tests to pass, but I got it close. Maybe we can discuss later today.
2 participants
The alpha release of this tool had no tests whatsoever and we just smashed everything together to make it work. But now that we are gearing up to go live, and it's more likely that people will want to PR fixes, we should have some test coverage.
I added dependencies for controlling the local auth server, the file system, the "open in browser" functionality, the Point-Free server, and finally the "whoami" hook. With that done we can mock out a variety of scenarios to make sure everything works.
There are some known bugs in the tool now (for claude and when using
--path), but we will fix those in separate PRs with appropriate tests to show the fixes.