Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Remove specs from finagle-http tests. #292

Closed
wants to merge 8 commits into from
Closed

Remove specs from finagle-http tests. #292

wants to merge 8 commits into from

Conversation

adamdecaf
Copy link
Contributor

As a follow up to the smaller PR I issued before.

This PR removes specs from being used in the finagle-http tests (and re-name all tests/files to *Test). Some of the tests however did use mockito, so I've left that in. Let me know if that's something we should remove also.

Adam Shannon added 7 commits July 2, 2014 17:47
Problem

In order to upgrade to 2.11 (and as part of a larger twitter initiative)
specs has to be removed. This is one small step in doing so.

Solution

Remove specs, replace with the standard FunSuite / assert way of
testing.

Result.

Hopefully nothing will change. Except for removing specs.
@mosesn
Copy link
Contributor

mosesn commented Jul 8, 2014

Leaving the mockito bits in is fine. Could you refactor to use org.scalatest.mock.MockitoSugar? I'll update the coordination issue to also mention that.

@adamdecaf
Copy link
Contributor Author

Alright, MockitoSugar has been added.

@mosesn
Copy link
Contributor

mosesn commented Jul 11, 2014

LGTM! This is awesome.

@stevegury
Copy link
Contributor

LGTM!

@alexflav23
Copy link

@mosesn Being equally excited about the complete move to ScalaTest for Finagle, I keep wondering if there is any argument against using AsyncAssertions to asynchronously wait for results and ScalaTest support for running individual specs in parallel.

Is there any interop or legacy concern to consider? The outcome would be a massive drop in total test time(> 60%).

@mosesn
Copy link
Contributor

mosesn commented Jul 22, 2014

@alexflav23 have you tried it on any specific tests? My impression is that scalatest already runs suites in parallel by default, so I don't understand where the speedup would be coming from. However, I'm definitely interested in work to make tests go faster, so if you find experimentally that it works well, we would be happy to see it.

Maybe we should take this discussion off of this PR and move it either to an issue or to the mailing list?

@alexflav23
Copy link

@mosesn Makes perfect sense, I will continue this on the mailing list. The speed up comes from running every spec(not every file) in parallel and not blocking for results. Examples to come on the mailing list.

@stevegury
Copy link
Contributor

For the record, I'm pulling this internally.

@travisbrown
Copy link
Contributor

This is now on GitHub—thanks, Adam!

@travisbrown travisbrown closed this Aug 6, 2014
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants