Open danbraunai opened 4 years ago
Also note that we only plan on using the calc_dd_table method for the hackathon (the other methods may be used in the future though)
Thanks for the heads-up, Brewing1!
I've assigned myself to this. Anyone who wants to join me is welcome. I'm a fan of pair programming and happy to try mobbing as well.
I guess some tests in the api.py file could be useful now (maybe pytest with the Flask framework? -- i've never used flask so don't really know what's going on). Note that DDScore may not be built upon today
We now have a basic test of the calc_dd_table method. I'll keep this issue open since I plan to add a few more tests there and then look into testing the Flask server per Brewing1's suggestion.
I agree that the place for extensive testing of the underlying DD code is in the dds C++ project, not in our wrapper. They have an extensive library of test deals, though it's not clear to me that their test harness is effective.
I like the idea of mocking the C++ library for our tests, but at least for me the current test runs in under a second so I don't think mocking is necessary.
A javascript unit test framework would be nice too. A few years ago I choose for my personal project Jasmine. I don't remember specifically why I choose it. But I remember I was happy with features it offered. It looks like still maintained. My experience is old and I have only fragmented memory how to use it.
Should javascript tests be a separated issue? (If this is all about server side test then I would say yes.)
Note that the dds library itself is very widely used and verified, so bugs are far more likely to be introduced in our code vs the library itself (mocking the library for our tests might be good enough?).