search

MoritzLange / py-tedopa

Python library for simulating open quantum systems with continuous bosonic environments
BSD 3-Clause "New" or "Revised" License
11 stars 9 forks source link

Write more modular tests #3

Closed MoritzLange closed 6 years ago

MoritzLange commented 6 years ago

Write tests for the single functions instead of the already existing ones testing the program as a whole

MoritzLange commented 6 years ago

For most of the functions it seems to be difficult or pointless to write a test.

  1. Functions that call other functions requiring complex input and when done pass their findings up the stack (to the function that called them) (such as _trotter_slice())

    It would be difficult/work-intensive to write up a setup for a test that can be used as input to the function and one would have to hard code what exactly the expected output would be and check the elements one by one

  2. Functions that just sort, alter or extend lists (such as _get_h_list())

    These functions are so primitive that a test is not really required, and if they get changed probably the input or output format would change rendering the test useless

Which leaves only one function in tedopa.py to be checked and few in tmps.py. I think in this regard, having something checking the whole TMPS code, so that all the functions can call the respective lower level function and pass the results back up the stack (as is currently implemented with the transverse Ising model tests) makes more sense. A similar test for the TEDOPA code is missing as of yet, but I guess when the analytical results and the code output for coherences match and we are convinced that the outputs of tedopa are correct, this would be a good test, at least for tedopa1().

MoritzLange commented 6 years ago

Because of the above explanation I'll close this for now.