pact-python manages the mock service

[matthewbalvanz-wf]

• pact-python now manages the mock service process
• Moved the project to version v0.2.0

resolves #5 and possibly #7

@mefellows @jslvtr

[mefellows]

You're a machine! Great stuff.

[mefellows]

One thing to consider is when the verification call is made. You may want to consider exposing this to the DSL somehow to the user. In larger Pact tests, if you have several request/response related unit tests but one of them doesn't call the mock service correctly, you won't know if it fails until the process exists (based on what I can glean, this occurs usingatexit and

pact-python/pact/pact.py

Line 221 in 4bf7b8b

def __exit__(self, exc_type, exc_val, exc_tb):

).

This could make it hard to see why or where the test failed (i.e. which tests didn't send through the Interaction or sent an unexpected one).

[matthewbalvanz-wf]

One thing to consider is when the verification call is made...

Python has a concept called context managers that allow you to run code before and after a block, for example:

pact = Consumer('Consumer').has_pact_with(Provider('Provider'))
with.pact:
    # perform my tests

Before my tests __enter__ is called, after __exit__ is called. __exit__ performs a verification. You do make me think that might not be flexible enough, and that using start/stop as the methods to launch and teardown the Ruby mock service may lead to confusion.

I'll ponder that for a bit and may rearrange some things to make it more clear.

[mefellows]

Is that at the test class level or individual tests? Another thing to consider is that people may break up tests to a single provider across files as pact tests can be quite lengthy, and that they'll need to use the same running mock server for all of them (this will be made easier when we get the shared lib). That being said, having an opinionated workflow isn't necessarily a bad thing.

[matthewbalvanz-wf]

@mefellows I pulled out the setup/verify logic to separate methods so users now have two ways to use the Pact:

1. As a context manager with the with statement, which calls setup before running the code in the block, and verify after the block completes
2. Manually calling setup and verify in their code.

I also renamed the start and stop methods to start_service and stop_service to make it more obvious what they were doing.

[mefellows]

That seems like a great compromise @matthewbalvanz-wf!