If you are trying to put structure to your code, you would like to get instant feedback on how that structure works from the outside. That is how the api works,

If you are trying to put structure to your code, you would like to get instant feedback on how that structure works from the outside. That is how the api works, the best way to do is to make a test which actually uses your code, and asserts some invariants on it. With tdd the idea is you write a test first to explore how your code should be called, then you make that code, satisfy the test and add more requirements and repeat the whole thing. Once you have a bunch of tests which are defining the use cases in your code, you can refactor/structure your code internally without affecting the tests or if you think the whole api could be simpler, change the whole thing along with tests. The refactoring at this stage is generally of higher quality since you have a concrete idea of all the ways your code needs to work while as if you refactor early there is little guarantee that it's any good except for intuition. If you are structuring or abstracting without examples of how your code is to be used, then the design often turns out to be inefficient, overly complex, coupled or over abstracted. Admittedly this TDD approach is a bottom up design method, it takes time and effort and it's not well suited for problems where you already have a good idea of how code should look like/feel/behave. You don't need to run these tests every time in ci, you can delete them or keep them as documentation or run them whenever you have to work on the code again.