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 some testing infrastructure for feature testing examples #299

Merged
merged 23 commits into from Jan 14, 2016

Conversation

Ryman
Copy link
Member

@Ryman Ryman commented Nov 21, 2015

I'd like to make an attempt soon to refactor some of the internals so that we can actually do decent unit-testing, and to remove some gotchas. To do so with any confidence we need to have some end-to-end tests in place to make sure nothing major breaks.

I've made a start here but there are many examples still not covered, most notably the large example.rs/macro_example.rs. We should split that example into several more focused examples with better documentation as I can only imagine a new user is unable to really understand what features are available when the entire sink is thrown at them. EDIT: example.rs has been split, macro_example.rs is left for future

Feedback and suggestions are extremely welcome, this feels pretty hacky, but it's the most effective way I could think of getting a decent baseline without potentially introducing errors (by making internal code easier to test).

@@ -156,7 +157,15 @@ impl<D: Sync + Send + 'static> Nickel<D> {
});

let server = Server::new(self.middleware_stack, self.data);
let listener = server.serve(addr, self.keep_alive_timeout).unwrap();

let is_test_harness = env::vars().any(|(ref k, _)| k == "NICKEL_TEST_HARNESS");
Copy link
Member Author

Choose a reason for hiding this comment

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

This is probably the part with the biggest smell.

Alternatives:

  • change all the examples to run on a random port (which is what I did in similar tests for nickel-mustache). The downside of that approach is that users who copy the examples have to actually pay attention to the port (and it can change between server reboots).
  • use something more standard such as $PORT if it exists, which might be beneficial for users who want to deploy on something like Heroku (I certainly have a tendency to always forget about setting this)
  • update examples to read their port from stdin. This is potentially something the user would add themselves, which would help them, but can add some verbosity to examples.

Copy link
Member

Choose a reason for hiding this comment

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

Can you clarify why the examples can't just keep running on one defined port? I'm assuming it's because it would prevent us from running multiple tests in parallel but as far as I understood it so far that won't be the case anyway because cargo doesn't work well in parallel either.

Copy link
Member Author

Choose a reason for hiding this comment

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

The server in the example will fail to bind to the port "6767" as it's in use, which will currently panic.

Builds are sequential, but testing (and running the build artifacts) is still in parallel. Sadly at least on my machine, likely due to multirust, a call to cargo build when it builds nothing still takes a second, so it often means things happen sequentially anyway, but occasionally I do see some tests happening in parallel. This will definitely be true for more complicated tests which may be less instantaneous.

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha! I'm also for $PORT then

@SimonTeixidor
Copy link
Member

This is great! Is it possible to export the util methods so that it can be used by middleware developed in a separate repo?

I'd like to see a $PORT being used if available. As you say, it should make it easier to deploy apps on different platforms.

@cburgdorf
Copy link
Member

That's super super cool! I left a note regarding the port thing but it's probably just me not seeing the forest for the trees ;)

@Ryman
Copy link
Member Author

Ryman commented Nov 21, 2015

This is great! Is it possible to export the util methods so that it can be used by middleware developed in a separate repo?

tl;dr: yes, but not yet

I'd like to extract it in future, but was hoping to keep it private and unstable until we discover the core useful interface would be. Definitely think it's worth waiting until the remaining examples are under test before continuing with that.

I'd like to see a $PORT being used if available.

Vote counted!

@Ryman
Copy link
Member Author

Ryman commented Nov 24, 2015

So, when I sat down to implement the switch to $PORT, I realised there's a couple of problems which makes it even worse:

  • different semantics: NICKEL_TEST_HARNESS means do something different due to a test harness being present and can just bind to localhost, PORT on the other hand should have a port value which means we need to adjust the addresses being input.
  • We currently take server.listen(foo) where foo implements ToSocketAddrs. One way of overriding the port from this is to call the to_socket_addrs and update the ports for each SocketAddr in the list (assuming it parses correctly). Another would be to append a new binding to localhost:$PORT which may not be the best thing, as below. Both of these approaches seem rather hacky though.
  • If the aim of PORT is to make it easier to get running on heroku and such, then the default binding should probably be to 0.0.0.0 rather than localhost. On the other hand, we should not default to that for local servers.

I'm not exactly sure what the best fix is, but I'm starting to lean on NICKEL_TEST_HARNESS being OK as a private implementation detail for now.

@cburgdorf
Copy link
Member

but I'm starting to lean on NICKEL_TEST_HARNESS being OK

I'm the last person to criticize for that ;)

@Ryman
Copy link
Member Author

Ryman commented Nov 25, 2015

Rebased with comment about zero port being random.

Do we just go ahead with this for now or does anybody have a neat suggestion about my last comment?

@homu
Copy link
Contributor

homu commented Jan 14, 2016

⚡ Test exempted - status

@homu homu merged commit 22c8026 into nickel-org:master Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Otherwise, cargo test will try to run each .rs file within the tests folder
which will fail as many of them are intended to be submodules.

Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
homu pushed a commit that referenced this pull request Jan 14, 2016
Pull request: #299
Approved by: SimonPersson
homu pushed a commit that referenced this pull request Jan 14, 2016
…re examples

Pull request: #299
Approved by: SimonPersson
@Ryman
Copy link
Member Author

Ryman commented Jan 14, 2016

Well that was unexpected

@cburgdorf
Copy link
Member

Erm...did homu just shake up master a bit?

@cburgdorf
Copy link
Member

Ah, just a late merge it seems? So, everything is fine, ya?

@Ryman
Copy link
Member Author

Ryman commented Jan 14, 2016

I think so, do you mean the build failure in the travis history (and resulting email)? I'm not exactly sure what causes that but it seems to not be a real issue?

@cburgdorf
Copy link
Member

I just read your comment and saw this huge bunch of commits landing in master and for a moment thought homu did something wrong. Never mind me ;)

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

4 participants