Add unit test for SimpleArray

[KHLee529]

This is a follow up of PR #444 that test the constructor of SimpleArray.

[yungyuc]

Please review the CI failures. And please make sure all tests are clean before filing a PR.

[yungyuc]

@ThreeMonth03 The profiler test is not stable. When running it locally I can feel its slowness too. Those are 2 issues. Could you please help take a look at the first and we find time to discuss for the second.

GHA log https://github.com/solvcon/modmesh/actions/runs/12493102514/job/34861154319?pr=445#step:10:348 :

[----------] 4 tests from CallProfilerTest
[ RUN      ] CallProfilerTest.test_print_result
[       OK ] CallProfilerTest.test_print_result (61 ms)
[ RUN      ] CallProfilerTest.test_simple_case1
[       OK ] CallProfilerTest.test_simple_case1 (61 ms)
[ RUN      ] CallProfilerTest.simple_case_2
make[4]: *** [gtests/CMakeFiles/run_gtest] Error 1
/Users/runner/work/modmesh/modmesh/gtests/test_nopython_callprofiler.cpp:154: Failure
make[3]: *** [gtests/CMakeFiles/run_gtest.dir/all] Error 2
Value of: diff_time(node1->data().total_time, uniqueTime1 + uniqueTime2 + uniqueTime3)
make[2]: *** [gtests/CMakeFiles/run_gtest.dir/rule] Error 2
  Actual: false
make[1]: *** [run_gtest] Error 2
Expected: true
make: *** [gtest] Error 2
/Users/runner/work/modmesh/modmesh/gtests/test_nopython_callprofiler.cpp:160: Failure
Value of: diff_time(node2->data().total_time, uniqueTime1 + uniqueTime2)
  Actual: false
Expected: true
/Users/runner/work/modmesh/modmesh/gtests/test_nopython_callprofiler.cpp:166: Failure
Value of: diff_time(node3->data().total_time, uniqueTime1)
  Actual: false
Expected: true
[  FAILED  ] CallProfilerTest.simple_case_2 (166 ms)
[ RUN      ] CallProfilerTest.cancel
[       OK ] CallProfilerTest.cancel (0 ms)
[----------] 4 tests from CallProfilerTest (289 ms total)

[tigercosmos]

I will prefer to put the code at test_buffer.py, where we put all other array tests.

[yungyuc]

I concur. Do not add a new test file for this simple test.

[KHLee529]

@yungyuc @tigercosmos thanks for the suggestion, I'll inform you after I review and refine the code.

[KHLee529]

@yungyuc I've moved the test into test_buffer.py and fixed linter error.

[yungyuc]

Please also test using the original testing code in issue #437:

import unittest
from modmesh import SimpleArrayUint64, SimpleArrayFloat64
import numpy as np

class TimeBuffer(unittest.TestCase):
    a = np.ndarray(shape= (5,5,5,5), dtype=float)
    for i in range(5):
        for j in range(5):
            for k in range(5):
                for l in range(5):
                    a[i,j,k,l] = i*1000 + j*100 + k*10 + l

    b_copy = SimpleArrayFloat64(array=a)
    print(b_copy.ndarray)

Also address the following:

• L440: Use more interesting shape.
• L441: Use string for dtype.

[yungyuc]

Use string for the argument dtype, i.e., write dtype='float64'. modmesh uses a convention to use string for numpy dtype argument.

[KHLee529]

OK I'll fix it

[yungyuc]

Could you please also test with the shape in which each element different from others? (2, 2, 2, 2) is too simple.

[KHLee529]

No problem, I'll make it to (2, 3, 5, 7).
Here, I'm somehow curious about how to measure how "interesting" the shape is. I don't really know how to make the number reasonable but still effective as a test case. For example, (111, 222, 333, 444) might be an unreasonable test case due to its huge memory consumption.

[yungyuc]

(2, 3, 5, 7) looks sufficiently interesting.

[yungyuc]

Please leave a global comment every time when you are ready for requesting the next review.

[KHLee529]

@yungyuc Oh, thanks for reminding. Now is ready for next review!

[yungyuc]

I make some tweaks and rebase to the latest master.

[yungyuc]

Use np.array instead of np.ndarray. The latter is not a numpy coding convention. We do not usually directly call the ndarray constructor. Instead, we use the helpers array, empty, ones, zeros, full, etc.

[yungyuc]

The testing code looks good. I squashed all changes to prepare for merging.