Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

thinking-tests

Package Overview
Dependencies
Maintainers
1
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

thinking-tests

Declarative API over unittest with customizable auto-discovery, test lifecycle and handy integrations

  • 0.0.4
  • PyPI
  • Socket score

Maintainers
1

thinking-tests

CI PyPI version

Part of thinking family.

Declarative API over unittest with customizable auto-discovery and test lifecycle.

Requires python 3.12. Is mostly typed.

What started as fluent, decorator-based API over unittest, grew into a facade that uses unittest as testing backend, while providing bunch of report and integrating coverage too.

Is heavily based on thinking framework pieces, so you better get acquainted with thinking-runtime.

Usage

Declaring tests

Put your tests into package lying in repository root. This assumption is important for discovery, but also a good practice.

For this part you need decorators module:

from thinking_tests.decorators import case, setup, teardown

You declare test cases with decorator:

@case
def my_case():
    assert 1 + 1 == 2 

You can tweak setup and teardown with context managers:

def my_setup():
    ...

def my_teardown():
    ...

with setup(my_setup), teardown(my_teardown):
    @case
    def my_case():
        ...

Running tests

Use the __name__ == "__main__" idiom and run_(all|current_(module|package))() functions (from thinking_tests.running.start module).

  • run_all() will scan the current root package for test cases and run them all
    • if you call that function from pkg.subpkg.module, it will scan every module (at any depth) in pkg package
  • run_current_package() will do similar thing, but will run all the tests in the same package (and lower) as from where you call it
    • e.g. if you have tests in pkg.sub.sub1.mod and pkg.sub.sub2.mod and call it from pkg.sub.run, it will pick up both these modules, but not cases defined in pkg.another.mod
  • run_current_module() will only run cases defined in the module where it is called

See test_fixture for an example usage - x and y modules will use if __name__=="__main__": run_current_module(), while run_all will have if __name__=="__main__": run_all(). That way you can have x and y suites, while being able to run all available tests with python -m test_fixture.run_all.

Reporting

thinking-tests come with JUnit XML and HTML reports, Coverage data files, XML reports and HTML reports out of the box.

By default all of them are enabled. Tha way you're set up for CI (which may consume unittest XML report and Coverage binary/XML report) as well as local development (where you probably wanna see report in nice, webbrowser-based UI).

Great kudos to vjunit and junit_xml authors, from which I stole the code before tweaking it for smoother experience.

Configuration

As mentioned, configuration is based on thinking-runtime bootstrapping mechanism. You can define your own __test__/__tests__/__testing__ config file, where you interact with thinking_tests.running.test_config.test_config object.

It has 2 properties:

  • unittest
    • exposes 2 str properties:
      • xml_report_path
      • html_report_path
    • both of them are resolved against repository root, if they are not None and are not absolute paths
    • if they are None, appropriate report is turned off
    • if XML report is disabled, HTML report must be disabled, or it will be an error
    • there are also (xml|html)_report_enabled and simply enabled properties
      • they have getters
      • they also have setters, but if you pass True, it will be an error - use them only to quickly turn off appropriate report
      • (...).enabled = False will set None to both paths
  • coverage
    • exposes 3 str properties:
      • binary_report_path - being the Coverage SQLite data file path
      • xml_report_path
      • html_report_dir - notice that it points to a directory, not a single file
    • they are also resolved against repo root, same as with unittest, and they are interpreted in the same fashion when they are None
    • binary report must be enabled for other reports to be enabled, or you'll get an error
    • you'll also find (binary|xml|html)_report_enabled and just enabled properties that behave similarly as with unittest
    • there are also properties passed directly to Coverage
      • they are:
        • branch: Optional[bool]
        • 'include: Optional[str | Iterable[str]]'
        • 'omit: Optional[str | Iterable[str]]'
      • they must be None (default) if binary report is disabled

Keywords

FAQs


Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc