Introducing service mocking feature

[4383]

Summary

Mocking features can help varlink users to simplify varlink client development and testing like python-podman by example.

This feature is useful for unit testing to quickly setup a varlink server based on a mock class who will return user defined values.

This feature avoid to setup an env with the server part to test our clients, and user can be focused on feature development and also merely unit test them with only a pur python environment.

The mock module introduce a function decorator and user can use it to start the mocked server and surround with it specific tests

Example

Users can use it like this, they define a mock class (Service) and they decorate their unit tests by using the mocking module, then they are able to communicate with the server and can test their API/client:

import unittest
from varlink import mock
import varlink

class Service():

    def Test1(self, param1: int) -> str:
        """return test"""
        return {"test": "test1"}

    def Test2(self, param1: str="test") -> None:
        pass

    def Test3(self, param1: str) -> str:
        """return test"""
        return {"test": param1}

class TestMockMechanisms(unittest.TestCase):

    @mock.mockedservice(
        fake_service=Service,
        name='org.service.com',
        address='unix:@foo')
    def test_init(self):
        with varlink.Client("unix:@foo") as client:
            connection = client.open('org.service.com')
            self.assertEqual(connection.Test1(param1=1)["test"], "test1")
            self.assertEqual(connection.Test3(param1="foo")["test"], "foo")

Questions/Thoughts

Are you interested by this kind of feature?

It's yet in WIP, I need to adjust things and class parser, but currently I use introspection on annotations to generate the interface from the given class and so it's not compatible with python 2.7, so if you are interested by these changes we have the following possiblities:

• finding another way to generate the interface file without using introspection on annotations, by using docstring by example... (a little bit crap... but do the work, annotations are more elegant)
• we assume to only support py3+ and we merge this with this project
• you offer to host a new project dedicated to these changes under the varlink organization which assume to only support py3+ and keep this project compatible with py2/py3 (a kind of project for testing purpose dedicated to the python community).

As I can observe on my side (python-podman) we spend many effort and time to finally more testing the server part rather the client part.

Thoughts?

[coveralls]

Pull Request Test Coverage Report for Build 227

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at ?%

---

Totals
Change from base Build 221:	0.0%
Covered Lines:
Relevant Lines:	0

---

💛 - Coveralls

[4383]

Observe example at work => https://travis-ci.org/varlink/python/jobs/566049293#L609

[haraldh]

Wow. Sounds cool. Will look into the details the next days

[haraldh]

Can we just provide the mock module only for py3+ and have the story, that if you want to test with mock services, you have to use py3+?

[4383]

We can only provide it for python3 but by deprecate python2. In other words currently you are compatible with the both version, we can introduce a new release of this project who is only compatible with python3.

We can't let the both version coexist, because the py2 interpretor will fail on module loading so...

Python2 is EOL and the final countdown is nearly finished (4 months).

Many distros have start to remove py2, on openstack too many dependencies have start to remove the compatiblity and openstack himself plan it soon, so it make sense to release a new version who is the beginning of this support ending and let python 2 go away....

We can tell to pip and pypi that this new release is only compatible with py3 so users who use py2 will continue to pull the right version.

My changes can introduce this support ending.

Thoughts?

[4383]

Many mainstream python libraries have removed the support of python2:

• https://github.com/openstack/requirements/search?q=python_version&unscoped_q=python_version
• https://github.com/openstack/requirements/blob/e021ce6144933d0443eb6342ebe8accd9066daa9/upper-constraints.txt (and then search for python_version: python_version)

[haraldh]

What about:

• modifying __init__.py load_tests() to exclude test_mocks.py for sys.version_info[0] == 2
• raise an ImportError for sys.version_info[0] == 2 in mock.py

[4383]

We can test this path, lets me try it :)

[4383]

Well I've introduce a new tox target specific to py27 and use it to exclude test_mock.py from tests under python 2.7.

So these changes are compatible with CI execution on travis and with local testing.

[4383]

Now I need to add doc, refactor some things in the fake service parser to generate more complex interface and better handle the return part.

CI is now fully happiest and me too :)

[4383]

Some doc added now

[haraldh]

Ready to merge?

[4383]

@haraldh nope please wait, I need to add some changes.

Please give me your feedback about the doc part and the example described inside, especially the way to handle return description for interface. (https://github.com/varlink/python/pull/15/files#diff-543d5415d68c042966797548d2ef888aR159)

It's not fully implemented especially on this part but I think I'll follow the previously described return management.

Also I've no idea how to manage Type so if you have an idea on your side feel free to share it.

[4383]

Well now that the week end is passed I have some ideas for the Type part, I guess add the possibility to pass types as a params too.

I want to add the Type part in a follow up patch to stay focus on the mock part and start to use these changes on python-podman who which give me feedback and other ideas.

Before merge these changes I want to clean some part of this code, I'll ping when it's ok for me.

[4383]

Well I've made some changes to clean my code, then it's look good to me now, it's ready for merger.

I'll continue to improve this feature in follow up patches.

When these changes will be merged can you release a new version to pypi to lets my pull these changes on the python-podman side, thanks.

[4383]

@haraldh if everything sound good for you can you merge this one?

This will allow me to continue my work on python-podman unit tests.

Thanks

[haraldh]

Thanks for the contribution. Will release a new version today.

[4383]

Excellent!

Thanks @haraldh

I think I'll back soon with more improvements.

[haraldh]

released 30.2.0

[4383]

Thank you