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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify agent communication in preparation for new wire protocol #762

Merged
merged 7 commits into from May 17, 2020

Conversation

jnm2
Copy link
Collaborator

@jnm2 jnm2 commented May 4, 2020

This cuts down on the amount of work needed to build the new protocol and it enhances the separation between ProcessRunner and all agency/agent concerns.

Review a commit at a time to follow the incremental changes.

  • Removes the ITestAgent.Start and ITestAgent.Id properties since they will not be remote procedure calls in the new protocol

  • Reinvents RemoteTestAgentProxy as IAgentLease so that TestAgency is in full control both of starting and stopping of agents and is the only thing with access to ITestAgent instances in the console process.

Looks like it nets six lines fewer 馃槉

@jnm2 jnm2 force-pushed the simplify_agent_communication branch from 74e3fdf to 3779fc2 Compare May 4, 2020 04:10
Comment on lines -35 to +29
internal class RemoteTestAgentProxy : ITestAgent
public partial class TestAgency
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nice, it even followed it.

@jnm2 jnm2 force-pushed the simplify_agent_communication branch from 3779fc2 to 82ede1e Compare May 4, 2020 04:18
@jnm2 jnm2 force-pushed the simplify_agent_communication branch from 82ede1e to 3b3b2e4 Compare May 4, 2020 04:29
Comment on lines -33 to -42
/// <summary>
/// Gets a Guid that uniquely identifies this agent.
/// </summary>
Guid Id { get; }

/// <summary>
/// Starts the agent, performing any required initialization
/// </summary>
/// <returns>True if successful, otherwise false</returns>
bool Start();
Copy link
Collaborator Author

@jnm2 jnm2 May 9, 2020

Choose a reason for hiding this comment

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

Do I understand correctly that all public nunit.engine and nunit.engine.core types are changeable in every release because consumers of the engine should only be referencing the nunit.engine.api assembly?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, that's my opinion. I want to enforce that in v4. 馃檪

Copy link
Contributor

Choose a reason for hiding this comment

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

In V3, we could at least tell people this.

Copy link
Member

Choose a reason for hiding this comment

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

A fair point. I went to take a look at what our current docs say. I think the first paragraph of this page covers that the API is the supported way to integrate with the engine?

https://github.com/nunit/docs/wiki/Test-Engine-API

I'd love to spin out the engine and console docs at some point, and build a little more structure around them. One day...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@ChrisMaddock your last comment showed up twice, so I deleted one of the copies.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that doc page says it well. I was only reacting to the "modern" view sometimes expressed that any public method being changed constitutes a breaking change.

Copy link
Member

@ChrisMaddock ChrisMaddock left a comment

Choose a reason for hiding this comment

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

Thanks for breaking this down the way you did - this was super-easy to follow and review! Looks great! 馃槃

@ChrisMaddock
Copy link
Member

Leave it with you as to whether you want to merge now, Joseph, or if you want other people to look over it first. 馃檪

@@ -56,8 +57,9 @@ public class RemoteTestAgent : TestAgent, ITestEngineRunner
/// Construct a RemoteTestAgent
/// </summary>
public RemoteTestAgent(Guid agentId, string agencyUrl, IServiceLocator services)
: base(agentId, services)
: base(services)
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand you, you are saying that only Remote agents need an agent ID, as apposed to all agents. Of course, it makes no difference since we have not yet created any other agent types. Are you willing to give up the option of other agents?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's not quite it. All agents still need an ID and still use it to register with the agency. I moved the ID out of the ITestAgent interface so that ITestAgent members can represent remote procedure calls. I'm not planning for the protocol to have a "Start" message to the agent or a "Get ID" message. But even though its storage location moved, the ID is still being used in all the same ways as before this PR, I think.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

(And the reason to make ITestAgent look just like the wire protocol is to enable incremental changes to get there, rather than doing the whole thing in one PR and implementing our current ITestAgent interface on top of that.)

@nunit nunit deleted a comment from ChrisMaddock May 9, 2020
@jnm2 jnm2 merged commit ba46db7 into nunit:master May 17, 2020
@jnm2 jnm2 deleted the simplify_agent_communication branch May 17, 2020 16:27
@jnm2 jnm2 linked an issue May 17, 2020 that may be closed by this pull request
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.

Planning: replacing remoting with custom protocol
3 participants