Research
Security News
Malicious npm Package Targets Solana Developers and Hijacks Funds
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Declarative API over unittest with customizable auto-discovery, test lifecycle and handy integrations
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
.
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():
...
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
pkg.subpkg.module
, it will scan every module (at any depth) in pkg
packagerun_current_package()
will do similar thing, but will run all the tests in the same package (and lower) as from
where you call it
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 calledSee 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
.
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.
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
str
properties:
xml_report_path
html_report_path
None
and are not absolute pathsNone
, appropriate report is turned off(xml|html)_report_enabled
and simply enabled
properties
True
, it will be an error - use them only to quickly turn off appropriate
report(...).enabled = False
will set None
to both pathscoverage
str
properties:
binary_report_path
- being the Coverage SQLite data file pathxml_report_path
html_report_dir
- notice that it points to a directory, not a single fileunittest
, and they are interpreted in the same fashion
when they are None
(binary|xml|html)_report_enabled
and just enabled
properties that behave similarly as with unittest
branch: Optional[bool]
None
(default) if binary report is disabledFAQs
Declarative API over unittest with customizable auto-discovery, test lifecycle and handy integrations
We found that thinking-tests demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
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.
Research
Security News
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.