Skip to content
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 unit tests for frames. #15

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

AasthaGupta
Copy link
Contributor

This PR includes unit test for the different frame type. It covers test cases for initialization, encoding, decoding and flag setting.

This will increase the code coverage from 0% to 64%.

Screen Shot 2021-01-28 at 6 16 41 PM

Signed-off-by: Aastha Gupta <aastha.gupta4104@gmail.com>
@OlegDokuka
Copy link
Member

OlegDokuka commented Jan 28, 2021

@AasthaGupta that is too early to add tests now. The API will be changed, so adding tests at this moment will just make it more challenging for us to break things when we find them less convenient.

At least, I would deffer mergin that until the internal implementation will be stabilized

Copy link

@nkristek nkristek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, well done and thank you! I have a few suggestions, otherwise very good!

Comment on lines +37 to +40
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadFollows.rawValue != 0, "Expected follows flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadComplete.rawValue != 0, "Expected complete flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadNext.rawValue != 0, "Expected next flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.metadata.rawValue != 0, "Expected metadata flag to be set")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of checking if the bits are equal OptionSet provides contains that can be used like:

Suggested change
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadFollows.rawValue != 0, "Expected follows flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadComplete.rawValue != 0, "Expected complete flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.payloadNext.rawValue != 0, "Expected next flag to be set")
XCTAssert(payloadFrame.header.flags.rawValue & FrameFlags.metadata.rawValue != 0, "Expected metadata flag to be set")
XCTAssert(payloadFrame.header.flags.contains(.payloadFollows), "Expected follows flag to be set")
XCTAssert(payloadFrame.header.flags.contains(.payloadComplete), "Expected complete flag to be set")
XCTAssert(payloadFrame.header.flags.contains(.payloadNext), "Expected next flag to be set")
XCTAssert(payloadFrame.header.flags.contains(.metadata), "Expected metadata flag to be set")

Comment on lines +48 to +60
func testPayloadEncoder() {
let payloadMetadata = "m".data(using: .utf8)!
let payloadData = "d".data(using: .utf8)!
let payloadFrame = PayloadFrame(streamId: 1, fragmentsFollow: true, isCompletion: true, isNext: true, payload: Payload(metadata: payloadMetadata, data: payloadData))

guard var byteBuffer = try? PayloadFrameEncoder().encode(frame: payloadFrame, using: ByteBufferAllocator()) else {
XCTFail("Expected byte buffer to be not nil")
return
}

XCTAssertEqual(byteBuffer.readableBytes, 11)
XCTAssertEqual(byteBuffer.readBytes(length: byteBuffer.readableBytes), PayloadFrameTests.bytes)
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a suggestion and fine if we don't apply it, but we could also define the enclosing method to be throwing:

Suggested change
func testPayloadEncoder() {
let payloadMetadata = "m".data(using: .utf8)!
let payloadData = "d".data(using: .utf8)!
let payloadFrame = PayloadFrame(streamId: 1, fragmentsFollow: true, isCompletion: true, isNext: true, payload: Payload(metadata: payloadMetadata, data: payloadData))
guard var byteBuffer = try? PayloadFrameEncoder().encode(frame: payloadFrame, using: ByteBufferAllocator()) else {
XCTFail("Expected byte buffer to be not nil")
return
}
XCTAssertEqual(byteBuffer.readableBytes, 11)
XCTAssertEqual(byteBuffer.readBytes(length: byteBuffer.readableBytes), PayloadFrameTests.bytes)
}
func testPayloadEncoder() throws {
let payloadMetadata = "m".data(using: .utf8)!
let payloadData = "d".data(using: .utf8)!
let payloadFrame = PayloadFrame(streamId: 1, fragmentsFollow: true, isCompletion: true, isNext: true, payload: Payload(metadata: payloadMetadata, data: payloadData))
var byteBuffer = try PayloadFrameEncoder().encode(frame: payloadFrame, using: ByteBufferAllocator())
XCTAssertEqual(byteBuffer.readableBytes, 11)
XCTAssertEqual(byteBuffer.readBytes(length: byteBuffer.readableBytes), PayloadFrameTests.bytes)
}

@nkristek
Copy link

@AasthaGupta that is too early to add tests now. The API will be changed, so adding tests at this moment will just make it more challenging for us to break things when we find them less convenient.

At least, I would deffer mergin that until the internal implementation will be stabilized

Frame logic can be tested imho, it shouldn't change that much anymore. I will add some convenience soon that builds on the existing logic.

@OlegDokuka
Copy link
Member

OlegDokuka commented Jan 28, 2021

@nkristek
Right, the framing logic itself - true. Encoders - I would disagree. As we discussed, we can add more improvements to the existing codecs API. From my personal experience, writing tests for unstabilized API end ups in slowing down the whole development and research process. So when you have to rework the API or try out a new technique, apart from core changes you either have to maintain the tests or you usually comment/remove them entirely since they do not applicable or too hard to change them quickly. I'm fine if that great effort will be merged when we have the core part 90% implemented and stabilized and we know that what we have done unlikely to be changed.

Please, don't take me wrong, tests are inevitable, but I'm pessimistic about merging/doing that work now based on my experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants