Unit Tests

I keep all reusable code separate from app-specific code, and write a test function for each reusable function. Each file has an extra function that runs all the test functions within it.

jewish milk

writing untestable code

I'll admit these are issues I'm actively trying to work out.

your coding style gets better if you use unit testing but don't bother to force unit tests on dogshit code because you will have to introduce functions that you don't use in production and worse.

Pretty sure he meant the nose not the milkers

Then his eyes are undeserved.

fuck no, you only write unit tests so you can say "not my problem" in a business setting.

that being said, your code being easily testable is a good smell test so nice book.

>these are issues I'm actively trying to work out
Sounds like good reason to do it, then?

What makes code well testable?

You certainly have to have code that is written in a test friendly fashion, or be willing to rewrite some to make it easily unit testable. That said, your code shouldn't have to have anything special, testing specific to be testable code, as long as you have a good unit test/mocking framework.

Writing unit tests for your code may or may not be worth it depending on several factors like how much you care that your code actually works, how often it will be modified/expanded upon, and how cheap/fast manual testing is in comparison to writing unit tests. In my experience as someone who used to never write unit tests even as a professional developer but then one day had to because of the company I worked for, after about a year of getting used to writing unit tests for most of my code I will usually find unit tests very valuable and worth the time. The biggest time investment is really learning how to write unit tests and how to write testable code in general, and also in your language/testing framework of choice. Once you understand it writing more tests isn't that big of a time investment in the grand scheme of things.

Fuck unit tests. Test the program as a whole before each release, and then find/fix bugs as appropriate. You're shipping a finished executable, not code.
If you're writing a library, then test each exported API of course.

single responsibility
dependency injection
SOLID principles

I know what he meant.

Yes, probably not for exercism, but definitely for personal projects. Consider the amount of debugging that you will do, every single shit that you type on the console or whatever, you suddenly won't have to do any of that anymore if you have a test for it. Maybe start counting, count the time, and see if it is worth it?