I'm looking for a resource (book, website, etc) about the two topics of unit tests and test-driven development. I know the basic idea of each from the great wikipedia, but I have a hard time understanding how it could be applied to any real software system. In the last several projects I've worked on, it seems like all the systems involved were far too complicated for test cases to do more than cover the most trivial of cases. For example, I implemented the original Lisp from John McCarthy's paper "Recursive Functions of Symbolic Expressions and their Computation by Machine" in C++, and it involved writing a memory manager and several inter-recursive functions. In order to test any part of the system, the whole thing had to be tested, and there are no clear 'boundary conditions' that make themselves obvious as test points. The tests I eventually constructed were just random examples in the paper of programs and what they should evaluate to, and each test ended up being something like 50 lines of code when the whole rest of the program was around 500 lines. It just doesn't seem reasonable to have tests that test so little and yet are so big, so I have the strong feeling that I'm doing something significantly incorrect and/or I just don't get it. Thus, I'm looking for some resources that might help me fix this problem in future projects so they can be better tested.

Quote:Original post by SiCrane
Try Object Mentor's published articles, especially the Craftsman series.

It's probably not good that the main thing that sticks in my mind as I read the code in the Craftsman articles is "Eww! Not Thread Safe!"

Quote:Original post by Extrarius

Quote:Original post by SiCrane
Try Object Mentor's published articles, especially the Craftsman series.

It's probably not good that the main thing that sticks in my mind as I read the code in the Craftsman articles is "Eww! Not Thread Safe!"

Thread safety is overrated.

Quote:Original post by truthsayer
Thread safety is overrated.

You make a compelling argument, I'm convinced.

Quote:Original post by rip-off

Quote:Original post by truthsayer
Thread safety is overrated.

You make a compelling argument, I'm convinced.

Should every class be thread safe?

Of course not. But a blanket statement does not an argument make. Especially considering that we now program in the era of multiple cores.

Quote:Original post by rip-off
Of course not. But a blanket statement does not an argument make. Especially considering that we now program in the era of multiple cores.

And the solution to that is languages with good concurrent programming models, not "OMG make stuff thread safe with locks!".

Quote:Original post by SiCrane

Quote:Original post by truthsayer
And the solution to that is languages with good concurrent programming models, not "OMG make stuff thread safe with locks!".

You seem to have a very narrow idea what thread safety means. A function can be thread safe without locks.

Okay then, if you want to be fussy, the problem isn't just locks but anything using a shared memory model. Swappings locks for DCAS doesn't make it any better.