instead of? IMO You ARE writing the proper test. If your API doesn't have state, your throwaway UI will have imparted the same test coverage as a repeatedly running unit test where it matters. If your API has state, well ...

IMO, It's the same idea with REPL-driven development in a functional language, why write unit tests if an interface is impossible to behave differently over time without changes?

Typically someone then argues, well, what if you change the implementation. To that person I will point out that the change will be developed in a REPL just like the original version, and thus be tested when it hits. Oh well...

To some, QA means a lot of compute and green outputs, to others, QA means spending quality hammock time before hitting the REPL :)