This post makes the strongest argument I can think of in favor of testing: you're doing it anyway, so why not keep them? I don't know anyone who doesn't write a little main or side program to test out the code they have created. Unit testing can amount to nothing more than just keeping those tests in a file that runs periodically and flags raises a notice when they no longer work. Usually the "problem" is that the code has changed and the test needs to be modified, but sometimes the problem is an error introduced into the code.
TDD is a slightly harder sell, because it isn't how most people normally code. TDD folks strongly believe that once you train your mind to think this way, it's the right way to go. I don't write code this way, though. I do what I described above.
The problem arises when it starts to become very difficult to write tests, and the scenario I described above no longer applies. If you're writing something that can be tested through simple main style program, no problem. But what if you need to test a UI element, or a service, or something immensely database oriented (that would require writing extensive mocks just to do the test). A good framework should make this easily testable, but they don't always. There's a limit to how much I'll bend over backwards to unit test something. In this case, maybe integration tests are the best way to still get some coverage.
Why don't you just automate the REPL tests so they can be done for you? Whatever you type in the REPL, add it to the test suite. Whatever you check as output, that's your set of assertions. It will save you a whole lot of time in the future.
Why should I bother to convert tests from REPL? I use REPL for experiments along with testing. When I done experimenting I also done testing. When I'll return there, it would be for another experiment, significant part of my previous tests won't run again.
Also, I work mostly with pure functions and strong type systems. Those functions won't change their behavior if I change something in the system. These types won't let slip something bad that is hard to find.
TDD is a slightly harder sell, because it isn't how most people normally code. TDD folks strongly believe that once you train your mind to think this way, it's the right way to go. I don't write code this way, though. I do what I described above.
The problem arises when it starts to become very difficult to write tests, and the scenario I described above no longer applies. If you're writing something that can be tested through simple main style program, no problem. But what if you need to test a UI element, or a service, or something immensely database oriented (that would require writing extensive mocks just to do the test). A good framework should make this easily testable, but they don't always. There's a limit to how much I'll bend over backwards to unit test something. In this case, maybe integration tests are the best way to still get some coverage.