Skip to content

Add unit tests for Function API, declare_types, and code renderers#1835

Open
nishantraghuvanshi wants to merge 1 commit into
brian-team:masterfrom
nishantraghuvanshi:add/unit-tests-for-functions
Open

Add unit tests for Function API, declare_types, and code renderers#1835
nishantraghuvanshi wants to merge 1 commit into
brian-team:masterfrom
nishantraghuvanshi:add/unit-tests-for-functions

Conversation

@nishantraghuvanshi
Copy link
Copy Markdown

Starting on #1645

Summary

This is a first step towards addressing the issue of replacing integration tests with proper unit tests. Rather than running the full simulation machinery, these tests call the relevant functions directly.

24 tests are added to a new file brian2/tests/test_functions_unit.py.
All are marked @pytest.mark.codegen_independent and the full file completes in ~2 seconds.

What was converted and how

Several behaviours that were only tested by building a NeuronGroup and calling run(0*ms) are now tested directly:

Pure extraction (no mocking needed): the logic was already decoupled from the simulation:

  • Symbolic constants (pi, e, inf) have correct float values
  • CPPNodeRenderer correctly maps infINFINITY, booleans, **_brian_pow, %_brian_mod
  • NumpyNodeRenderer correctly rewrites and& and notlogical_not
  • @declare_types sets _arg_types/_return_type and validates type strings at decoration time
  • Function() constructor validates missing units and raises immediately

Mocking-based: the logic was coupled to heavy infrastructure, so I use MagicMock to isolate it:

  • check_expression_for_multiple_stateful_functions (detects rand() - rand()) is called directly with a minimal Function object instead of going through NeuronGroup + run()
  • check_for_order_independence is tested with a MagicMock standing in for ArrayVariable — the function only calls isinstance(var, Function) and isinstance(var, Constant), so a plain mock correctly represents a regular array variable without needing a device, owner, or size

Questions

  • Is this the right approach and structure to move forward with?
  • Should the new unit tests live in a single test_functions_unit.py or alongside the original test files (e.g. directly in test_functions.py with appropriate markers)?
  • Are there specific modules or integration tests you would prioritise for conversion next?

Happy to iterate on this based on feedback before expanding to other parts of the test suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant