4 ms·
In my chemical engineering work, I have often private routines I want to test. Pardon me, but this is Fortran code, so I cannot have "complex" class structures
by Loic 5y ago
In my chemical engineering work, I have often private routines I want to test. Pardon me, but this is Fortran code, so I cannot have "complex" class structures to allow different level of testing without complicating the code too much and making it unreadable.
The solution is "stupidly simple". I have at my module level a public subroutine with the name "test_module" which performs the tests of all the private subroutines of the module I want to test (these are usually analytical derivative calculations and stuff like that).
Yes, I have test code in my module, but in practice, after 10+ years of using this pattern, nobody had issues with it.
- feanaro 5y agoThis is also the recommended way of structuring things in Rust. It works pretty nicely.
- dirkf 5y agoIn the C world I sometimes do something similar: the C file with the test code simply #include's the actual source file and gets compiled into one executable (together with some mocks). Not too dirty (ahem...) and allows you to test various internal parts. And I must admit I got the idea after looking into Rust :)
- JonChesterfield 5y agoIn C I just write the tests in the same source files as the things they're testing. Some interface tests get their own source file. All the tests end up in the "release" binary, along with the application code. Separate test_main entry point to run the tests instead of the application. If I don't want the tests available, marking test_main static and deadstripping rips them all out.
- thot_experiment 5y agoI'll have to keep this in mind for the future, it seems like the KISS solution to the problem.