Flutter-geolocator: Really hate static methods...

Created on 28 Apr 2021  路  3Comments  路  Source: Baseflow/flutter-geolocator

Previous version of the plugin I could instantiate a geolocator, was nice and my unit tests were really happy about it because geolocator could be mocked.

Now everything is static... Is there any new way that doesn't involve static methods ?

Most helpful comment

The link also suggests to create wrappers/ adapters/ shims for thirds party dependencies and mock those instead, for the specific reasons you mentioned. This way your are mocking only code that you own (as in you are the owner of the wrappers/ adapters/ shims).

This has the following benefits:

  • Abstracts the 3rd party API which makes it easier to replace when necessary;
  • Reduces the surface of the API to only the parts that your application needs, making the API easier to use and understand from the rest of your application;
  • Won't break all your tests when the 3rd party API changes.

I will close this issue, but feel free to continue the discussion ;)

All 3 comments

@jaumard I admit this might not have been the best choice I have made. However in my defence common practise on testing and application architecture in general suggests that you should not mock what you don't own (more reading here).

My suggestion would be to write a wrapper around the geolocator and mock the wrapper instead.

Your link is more about TDD than unit testing in general. Also if we don't mock it the test don't pass I suppose because there is no implementation on it when running test.

Also I want to check that geolocation is called in my code and check what I do with the result is correct. So many reason you want to mock third party deps :)

Also don't mock deps using network and run your tests with no network, it will be fun :D or even with really show network and get 1 hour to execute your tests lol

But yeah I'll do my own wrapper around geolocator, just wondering if something was built in before doing it.

The link also suggests to create wrappers/ adapters/ shims for thirds party dependencies and mock those instead, for the specific reasons you mentioned. This way your are mocking only code that you own (as in you are the owner of the wrappers/ adapters/ shims).

This has the following benefits:

  • Abstracts the 3rd party API which makes it easier to replace when necessary;
  • Reduces the surface of the API to only the parts that your application needs, making the API easier to use and understand from the rest of your application;
  • Won't break all your tests when the 3rd party API changes.

I will close this issue, but feel free to continue the discussion ;)

Was this page helpful?
0 / 5 - 0 ratings