-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add "write" operation to HAConnection #55
Changes from 4 commits
85abcb5
0c97129
b29f5cc
a142192
da9887e
3168c92
476a426
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
/// Write audio data to websocket, sttBinaryHandlerId is provided by run-start in Assist pipeline | ||
public struct HASttData: Hashable { | ||
var sttBinaryHandlerId: UInt8 | ||
|
||
public init(sttBinaryHandlerId: UInt8) { | ||
self.sttBinaryHandlerId = sttBinaryHandlerId | ||
} | ||
} | ||
bgoncal marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1461,6 +1461,81 @@ internal class HAConnectionImplTests: XCTestCase { | |
let container = connection.caches | ||
XCTAssertEqual(ObjectIdentifier(container.connection), ObjectIdentifier(connection)) | ||
} | ||
|
||
func testWriteDataRequestAddsToRequestController() { | ||
connection.connectAutomatically = true | ||
let expectedData = "Fake data".data(using: .utf8)! | ||
let request = HARequest( | ||
type: .sttData(.init(sttBinaryHandlerId: 1)), | ||
data: [ | ||
"audioData": expectedData.base64EncodedString(), | ||
] | ||
) | ||
connection.connect() | ||
connection.send(request) { _ in } | ||
bgoncal marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean this literal closure here. The completion block for send() - can you test it is invoked? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The original implementation of the "send" method didn't have any usage of the completion. Should this be altered? |
||
XCTAssertNotNil(requestController.added.first(where: { invocation in | ||
if case let .sttData(sttBinaryHandlerId) = invocation.request.type { | ||
return sttBinaryHandlerId == .init(sttBinaryHandlerId: 1) && invocation.request | ||
.data["audioData"] as? String == expectedData | ||
.base64EncodedString() | ||
} | ||
return false | ||
})) | ||
} | ||
|
||
func testWriteDataRequestsCallCompletion() { | ||
let expectation = expectation(description: "Waiting for completion") | ||
let expectedData = "Fake data".data(using: .utf8)! | ||
let request = HARequest( | ||
type: .sttData(.init(sttBinaryHandlerId: 1)), | ||
data: [ | ||
"audioData": expectedData.base64EncodedString(), | ||
] | ||
) | ||
connection.connect() | ||
responseController.receivedWaitExpectation = expectation | ||
connection.requestController(requestController, didPrepareRequest: request, with: .init(integerLiteral: 1)) | ||
|
||
wait(for: [expectation], timeout: 5.0) | ||
} | ||
|
||
func testSendRawWithSttRequest() { | ||
connection.connect() | ||
let expectedData = "Fake data".data(using: .utf8)! | ||
let request = HARequest( | ||
type: .sttData(.init(sttBinaryHandlerId: 1)), | ||
data: [ | ||
"audioData": expectedData.base64EncodedString(), | ||
] | ||
) | ||
var expectedAudioData = expectedData | ||
expectedAudioData.insert(1, at: 0) | ||
|
||
connection.sendRaw(identifier: nil, request: request) | ||
waitForWorkQueue() | ||
XCTAssertNotNil(engine.events.first { event in | ||
event == .writeData(expectedAudioData, opcode: .binaryFrame) | ||
}) | ||
} | ||
|
||
func testWriteSttRequestCommand() { | ||
let expectedData = "Fake data".data(using: .utf8)! | ||
let request = HARequest( | ||
type: .sttData(.init(sttBinaryHandlerId: 1)), | ||
data: [ | ||
"audioData": expectedData.base64EncodedString(), | ||
] | ||
) | ||
let request2 = HARequest( | ||
type: .sttData(.init(sttBinaryHandlerId: 1)), | ||
data: [ | ||
"audioData": expectedData.base64EncodedString(), | ||
] | ||
) | ||
|
||
XCTAssertEqual(request.type.command, "") | ||
XCTAssertEqual(request.type < request2.type, false) | ||
} | ||
} | ||
|
||
extension WebSocketEvent: Equatable { | ||
|
@@ -1614,6 +1689,10 @@ private class FakeHAResponseController: HAResponseController { | |
receivedWaitExpectation?.fulfill() | ||
} | ||
|
||
func didWrite() { | ||
receivedWaitExpectation?.fulfill() | ||
} | ||
|
||
var receivedRestWaitExpectation: XCTestExpectation? | ||
var receivedRest: [Swift.Result<(HTTPURLResponse, Data?), Error>] = [] | ||
func didReceive(for identifier: HARequestIdentifier, response: Swift.Result<(HTTPURLResponse, Data?), Error>) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing this isn't invoking the completion blocks, but it may be useful to either wait to invoke it until the write occurs, or just invoke the completion right away. I know the server isn't ACK-ing this but it's still good form to be able to chain these together for throttling if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Communicating to the response controller isn't enough? like done here:
I noticed that when "sending" using websocket or rest, that's the only response, completion is not used for those either
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all of the tests check the invocation of the completion handler, but some do. e.g. testPlainSendSentSuccessful, testPlainSendSentFailurePromise, etc. You're making a new one with a unique code path, so you need to make sure all of the same guarantees happen somewhere.
The response controller only invokes based on identifiers - there's no identifier/callback for this write, so there's no way for it to know what to call back through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, got it, ok I added the identifier and a test to validate it, I also added this code block inside "sendWrite":
Because I can't add identifier to the data dictionary (since I am sending binary in this write) and it will also have no websocket event back from the connection.
Does that make sense?