Skip to main content
gamedev.net
🔒 Locked

Unit Tests and Test-Driven Development

Started by Extrarius 26 replies 7.7k views
Original Post
Extrarius
Extrarius
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.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
SiCrane
SiCrane
Try Object Mentor's published articles, especially the Craftsman series.
Extrarius
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!"
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
truthsayer
truthsayer
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.
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
rip-off
rip-off
Quote:
Original post by truthsayer
Thread safety is overrated.


You make a compelling argument, I'm convinced.
blog | twitter
truthsayer
truthsayer
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?
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
rip-off
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.
blog | twitter
truthsayer
truthsayer
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!".
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
SiCrane
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.
truthsayer
truthsayer
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.
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
SiCrane
SiCrane 
// thread safeint add(int a, int b) {  return a + b;}// not thread safeint add(int a, int b) {  static int accumulator;  accumulator = a;  accumulator += b;  return accumulator;}
truthsayer
truthsayer
Quote:
Original post by SiCrane
// thread safeint add(int a, int b) {  return a + b;}


There's no memory shared there.

Now try writing an entire program this way. It's not really possible in traditional languages built around the shared memory concurrency model, sadly.
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
SiCrane
SiCrane
Quote:
Original post by truthsayer
There's no memory shared there.

Exactly my point.
truthsayer
truthsayer
Quote:
Original post by SiCrane
Quote:
Original post by truthsayer
There's no memory shared there.

Exactly my point.


So you're talking about a completely uninteresting and trivial case. Congratulations must be in order.
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
silvermace
silvermace
Quote:
Original post by truthsayer
Quote:
Original post by SiCrane
// thread safeint add(int a, int b) {  return a + b;}


There's no memory shared there.

Now try writing an entire program this way. It's not really possible in traditional languages built around the shared memory concurrency model, sadly.


lol, get a clue.
truthsayer
truthsayer
Quote:
Original post by silvermace
lol, get a clue.


You must be that scholar I was looking for.

Care to explain yourself, or are you afraid your ignorance will shine through?
My rating perfectly reflects the pathetic yes-men in-crowd attitude of this forum.
Extrarius
Extrarius
Quote:
Original post by truthsayer
[...]There's no memory shared there.[...]
That is exactly my objection to the examples in the articles - they introduce shared memory for no reason, as far as I can tell. Perhaps it's a java thing (as I'm not familiar with all the details of java), but in C++ you could use exactly the same design with exactly the same variables but make it completely thread safe by passing around references to local objects instead of using global ones.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
sigsegv42
sigsegv42
Doh. Before the thread becomes completely derailed...
A selection of TDD articles over at Games from Within
Ashkan
Ashkan
Quote:
Original post by truthsayer
Quote:
Original post by silvermace
lol, get a clue.


You must be that scholar I was looking for.

Care to explain yourself, or are you afraid your ignorance will shine through?

Oh man, talk about unfriendliness. SiCrane is one of the more knowledgeable people I know on this forum and I know for a fact that he has no intentions but to help others. Dude, you seriously need to chill out.
Washu
Washu
Quote:
Original post by Ashkan
Quote:
Original post by truthsayer
Quote:
Original post by silvermace
lol, get a clue.


You must be that scholar I was looking for.

Care to explain yourself, or are you afraid your ignorance will shine through?

Oh man, talk about unfriendliness. SiCrane is one of the more knowledgeable people I know on this forum and I know for a fact that he has no intentions but to help others. Dude, you seriously need to chill out.

Nah, not anymore he doesn't... cus he's banned! Wee!

As far as the object mentor articles go:
Thread safety was not a primary concern when writing them, as threading was not not on the docket as far as concerns go for implementation of the problem they are approaching.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.