Skip to content
Test framework for comparing the consistency of library APIs
Python R Shell
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
.ci started adding more tests on (#143) Aug 21, 2019
.github Added CODEOWNERS file (fixes #108) May 26, 2019
smoke_tests fixed handling of cyclic imports (fixes #119) May 27, 2019
VERSION Add unit tests on PackageAPI and PackageCollection (fixes #52) Mar 6, 2019


PyPI Version Travis Build Status AppVeyor Build Status Documentation Status codecov Python Versions downloads license

doppel-cli is an integration testing framework for testing API similarity across languages.

What is the value of keeping the same public interface?

This project tests API consistency in libraries across languages.

Why is this valuable?

  • For developers:
    • less communication overhead implementing changes across languages
    • forcing function to limit growth in complexity of the public API
  • For users:
    • no need to re-learn the API when switching languages
    • form better expectations when switching languages

For more on this, click the link below to see this talk from the satRdays Chicago 2019 conference:

satRdays Chicago


For the most up-to-date documentation, please see

Getting started

doppel-cli can be installed from source just like any other python package.

python install

You can also install from PyPi, the official package manager for Python. To avoid conflicts with the existing doppel project on that repository, it is distributed as doppel-cli.

pip install doppel-cli

R requirements

In order to use doppel on R packages, you will need the R packages shown in the following installation commands:

Rscript -e "install.packages('argparse')"
Rscript -e "install.packages('futile.logger')"
Rscript -e "install.packages('jsonlite')"
Rscript -e "install.packages('R6')"

Example: Testing continuity between R and Python implementations

In this example, I'll show how to use doppel to test continuity between R and Python implementations of the same API. For this example, I used the argparse library.

NOTE: This example assumes that you already have argparse installed locally.

If you don't run one or both of these:

Rscript -e "install.packages('argparse')"
pip install argparse

First, you need to generate special files that doppel uses to store information about a project's API. These are created using the doppel-describe tool.


# Create temporary directory to store output files
mkdir $(pwd)/test_data

# The R package
doppel-describe \
    -p ${PACKAGE} \
    --language R \
    --data-dir $(pwd)/test_data

# The python package
doppel-describe \
    -p ${PACKAGE} \
    --language python \
    --data-dir $(pwd)/test_data

Cool! Let's do some testing! doppel-test can be used to compare multiple packages.

doppel-test \
    --files $(pwd)/test_data/python_${PACKAGE}.json,$(pwd)/test_data/r_${PACKAGE}.json \
    | tee out.log \
    | cat

This will yield something like this:

Function Count
|   argparse [python] |   argparse [r] |
|                   0 |              1 |

Function Names
| function_name   | argparse [python]   | argparse [r]   |
| ArgumentParser  | no                  | yes            |

Function Argument Names
No shared functions.

Class Count
|   argparse [python] |   argparse [r] |
|                   9 |              0 |

Class Names
| class_name                    | argparse [python]   | argparse [r]   |
| MetavarTypeHelpFormatter      | yes                 | no             |
| ArgumentParser                | yes                 | no             |
| FileType                      | yes                 | no             |
| HelpFormatter                 | yes                 | no             |
| RawDescriptionHelpFormatter   | yes                 | no             |
| Action                        | yes                 | no             |
| ArgumentDefaultsHelpFormatter | yes                 | no             |
| Namespace                     | yes                 | no             |
| RawTextHelpFormatter          | yes                 | no             |

Class Public Methods
No shared classes.

Arguments in Class Public Methods
No shared classes.

Test Failures (12)
1. Function 'ngettext()' is not exported by all packages

2. Function 'ArgumentParser()' is not exported by all packages

3. Packages have different counts of exported classes! argparse [python] (9), argparse [r] (0)

4. Class 'HelpFormatter()' is not exported by all packages

5. Class 'Namespace()' is not exported by all packages

6. Class 'RawDescriptionHelpFormatter()' is not exported by all packages

7. Class 'ArgumentParser()' is not exported by all packages

8. Class 'MetavarTypeHelpFormatter()' is not exported by all packages

9. Class 'Action()' is not exported by all packages

10. Class 'ArgumentDefaultsHelpFormatter()' is not exported by all packages

11. Class 'FileType()' is not exported by all packages

12. Class 'RawTextHelpFormatter()' is not exported by all packages

As you can see above, the argparse Python package has 9 exported classes while the R package has none.

From doppel's perspective, this is considered a test failure. If you run echo $? in the terminal, should should see 1 printed. Returning a non-zero exit code like this tells CI tools like Travis that the test was a failure, making doppel useful for CI (more on this in a future example).

You may be thinking "well wait, surely you'd want to test for way more stuff than just counts of classes and functions, right?". Absolutely! See the project issues issues for a backlog of features I'd like to add. PRs are welcomed!!!

To learn more about the things that are currently configurable, you can run:

doppel-describe --help


doppel-test --help


Bug reports, questions, and feature requests should be directed to the issues page.

See for information on how to contribute.

You can’t perform that action at this time.