You are testing four features in this one test. I would split these into separate tests, where you reuse the setup with the setUp() method:

def setUp() -> None:
    ...
    self.runtime = source.runtime
    ...

def test_implicit_run_steps_condition() -> None:
    self.runtime.start(run_condition=3)
    data = sink.data.get().astype(int).flatten().tolist()
    self.assertEqual(data, [0, 1, 2, 3, 4, 5, 6, 7, 8, 0])

def test_implicit_run_continuous_condition() -> None:
    self.runtime.start()
    time.sleep(0.02)
    self.runtime.pause()
    data = sink.data.get().astype(int).flatten().tolist()
    self.assertGreater(max(data), timestep + 10)

It may also be nice to add a little method for readability - just a thought:

def get_data(process: AbstractProcess) -> ty.List[int]:
    return process.data.get().astype(int).flatten().tolist()

def test_implicit_run_steps_condition() -> None:
    self.runtime.start(run_condition=3)
    data = self.get_data(sink)
    self.assertEqual(data, [0, 1, 2, 3, 4, 5, 6, 7, 8, 0])

And unless you expect users to use the runtime.start() method, I would test on the Process-level API

source = SourceBuffer(data=np.array(range(1000)).reshape((1, -1)))
source.run(run_cfg=Loihi2SimCfg(), condition=5)

Can we fix this inconsistency while we are at it? Why is one parameter called condition and the other run_cfg? Any of these combinations would make more sense to me:

• config and condition (prefer this)
• run_config and run_condition (okay)
• run_cfg and run_cndtn (ugh)

I also always get confused about which is which and look it up. Maybe there is a better naming entirely.

I agree completely and have considered making this change several times, unfortunately this will be breaking for user code, so we'd need to do a deprecation thing and I put it off before.

I'll look into whether it's possible to deprecate just an argument (run_cfg) and add config.

Do we really need to deprecate something at this stage? I feel we could start with that when reaching Lava version 1.0...

Just had this thought: When we have a Process with a PyProcModel that implements the AsyncProtocol, are we treating an iteration of the run() method as a "timestep"? I'm generally confused about these global time steps of the RunSteps condition when dealing with a network of Processes that run asynchronously.

Unknown. I don't believe AsyncProcess is actually working for most cases. Also, AbstractRunCondition is a bit silly in that it strongly implies that it will be an object that checks a condition, and that would be a nice, flexible pattern to use, but the reality is that when you pass a RunSteps, the actual integer gets accessed in quite a few different places and it doesn't have anything like a keep_running boolean method.

Here it is called run_condition rather than condition.

Yep.

Again, this overload is not necessary if we do not do it at the process level.

I am a little concerned that it may not be obvious what condition=10 means when they see this in a tutorial without context. Without knowing what a RunCondition is, they may think 10 is some magic number.

This is my main concern with this whole feature. Maybe it can be clarified by renaming the parameter?

I would also not prefer to overload. Add another API like run_for_timestep(...) and pipe that through this generic run API. But let's not overload the existing API.