Issue #435 :- solved test predict

[ayeankit]

Hey @sichinaga and @mtezzele , I have raised the pr for issue #435. Can you review it?

[ayeankit]

hey @mtezzele, Can please help me here, I couldn't find why GitHub actions is failing

[fandreuz]

Hi @ayeankit, could you please have a look at the tests close to that which you have refactored? We use a different test style:

• We don't usually use print statements to report the status of the test, since pytest will provide already enough details
• We don't need to catch assertion error

Note that if the test does not raise an AssertionError, pytest will assume it was successful even if it wasn't.

[fandreuz]

We don't need to adopt defensive programming in tests, letting the snippet fail if we can't load the test dataset is just fine

[sichinaga]

Hi @ayeankit! It's nice to meet you. :)

So one comment I want to make about this issue is that the main problem is not the test itself, but rather the data that the test is functioning on. Basically the original test should work just fine as long as the input to the predict method and the expected matrix make sense. At the moment, both are empty arrays, which is why the test technically passes, but it overall doesn't add much meaning to the testing suite.

Personally, my suggestion for fixing this test is to redefine the predict input and the expected matrix. If you notice what the predict function does [source], it's basically computing $\mathbf{A}\mathbf{x}$ for some input $\mathbf{x}$. So some expected behavior is that

$$ \mathbf{A}\mathbf{x}(t_k) \approx \mathbf{x}(t_{k+1}), $$

where $\mathbf{x}(t_k)$ and $\mathbf{x}(t_{k+1})$ are snapshots that we used to fit the DMD model. $\mathbf{x}(t_k)$ specifically denotes the snapshot at the $k$ th time step. We expect this because of how the DMD problem is formulated.