You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My initial idea was to separate testable code into a library and untestable code into a cli application. That's, in fact, why I'm obsessed with 100% coverage on it. But now it's clear that even though cli has specifics like fancy printers or progress bars, it doesn't mean they shouldn't be tested! They should, and mainly, because they can be tested, unlike Executable that implements Processer. I now have end up with _examples folder on which I check that cptest works as expected. Are we back to manual labor? I want to make sure that cli works as expected via tests, so that I don't need to check it manually. When #33 gets merged, the labor will be tripled (or even novemplied!)
The text was updated successfully, but these errors were encountered:
My initial idea was to separate testable code into a library and untestable code into a cli application. That's, in fact, why I'm obsessed with 100% coverage on it. But now it's clear that even though cli has specifics like fancy printers or progress bars, it doesn't mean they shouldn't be tested! They should, and mainly, because they can be tested, unlike Executable that implements Processer. I now have end up with _examples folder on which I check that cptest works as expected. Are we back to manual labor? I want to make sure that cli works as expected via tests, so that I don't need to check it manually. When #33 gets merged, the labor will be tripled (or even novemplied!)
The text was updated successfully, but these errors were encountered: