Added tests for server & bi-directional streaming

[cvanderschuere]

Following up on #144, these tests verify that #147 fixed the problem.

[MrMage]

Thanks a lot for this, it's great to see more cases of the API's usage covered with tests. I'll leave a full review to @timburks (he's the maintainer and knows this portion of the code better).

I think that it would be nicer to just have one or two extra test cases in EchoTests (possibly with a slightly customized version of EchoProvider), but I think the current generated server-side code would just "swallow" errors like that instead of returning them, so I guess this can't be tested in EchoTests right now.

Also, would you mind adapting your indentation to match the project's (2-spaces, no tabs)? Unfortunately, swift package generate-xcodeproj always resets that setting to the system defaults, maybe I can create a script to automatically change the defaults for the generated project.

[timburks]

This isEmpty condition should be inverted, i.e. it should be !string.isEmpty instead of string.isEmpty. Fortunately, our plugin test (make test-plugin) caught it!

If you don't mind, please update that in your PR. When the tests pass, I'll merge it.

Thank you!

[timburks]

With the inverted guard condition fixed, I'm still seeing a test failure on Linux:

/home/travis/build/grpc/grpc-swift/Tests/SwiftGRPCTests/GRPCTests.swift:253: error: gRPCTests.testConnectivitySecure : XCTAssertEqual failed: ("ok") is not equal to ("resourceExhausted") - 
Test Case 'gRPCTests.testConnectivitySecure' failed (0.045 seconds)

[cvanderschuere]

@timburks I cannot figure out what's going on here. There seems to be some sort of race condition, but nothing is standing out to me. I also cannot reproduce this error on OSX.

[timburks]

@cvanderschuere Have you tested on Linux? I'll try to reproduce this in a Linux VM.

[timburks]

@cvanderschuere I can confirm that the test fails on Ubuntu 16.04. The "ok" result is being set on this line which suggests that the operation group failed (and .ok should be something else, possibly .unknown). I'll continue investigating. Thanks for creating this test!

[timburks]

@cvanderschuere I don't think this line does what your comment suggests that it will do. @MrMage recently added that queue and from reading Call.swift, I think it only synchronizes message sends and not call starts.

Also, I think we need to add sem.wait() here to keep us from ending the call before the server has closed the connection.

Update: the test seems to consistently pass for me when I delete call.messageQueueEmpty.wait() and add sem.wait() at the end of func callBiDiStream(). And I think that this line can also be deleted.

[cvanderschuere]

@timburks Thanks for the help! I certainly misunderstood what messageQueueEmpty was doing and was stuck in not being able to reproduce the issues.

I made the changes you suggested and all looks to be well.

[timburks]

@cvanderschuere Thanks for working through this!