Unit Tests

Can somebody explain unit testing and test driven development? I've tried to learn it through blogs and code samples and such, but I just can't grasp it. It seems like a really backwards way of writing code. I've never really had a problem learning all kinds of programming concepts and methodologies in the past but this stumps me. Is it supposed to be a really difficult thing to learn or am I just retarded?

It's quite simple >>1, consider the words involved.
"Unit" is a ENG-US slang term for penis.
"Test" is obvious.
Hence to test a unit is to gobble a dong. This is known as homocoding in certain gay circles.

>>1 I think you are just retarded.

Say you have a program FOO and you need to add an add() function to it.  Using TDD, you would write some unit tests for add() first, e.g.:

    is( add( 1, 1 ),    2, "add(1,1)==2" );
    is( add( -1, -1 ), -2, "add(-1,-1)==-2" );
    is( add( -1, 1 ),   0, "add(-1,1)==0" );
    isnt( add( 2, 3 ),  6, "add(2,3)!=6" );

This sets some target tests that your function must meet.  These tests should cover the requirements specified for the new function.  At this point, you have 4 unit tests which will fail (because the code doesn't exist).  Now, you write the code to make these tests pass, e.g.

    int add(int a, int b) { return a + b; }

In this contrived, small example, it is difficult to see the benefits of doing it this way, but they are roughly:

* You are more sure you are meeting the specifications.
* You don't entirely skip writing the tests in a time crunch, which is easy to do, but unit testing is very important, and gives you confidence that your code is correct and makes it so that sweeping changes or refactoring your code later is much easier.
* In more complex feature additions, if you are sure your tests are correct and cover the specs, if your first one or two tries adding the features don't pass the tests, you can just delete your attempt and start over from scratch, instead of painstakingly debugging your code.  Debugging will always necessary, but if you can minimize the time spent doing so by working smarter, you can be more productive overall.

using asserts gives both the advanages of debugging and testing. You just verify parts of your code are giving the results you expect with asserts, it eliminates the need to make driver code to run your program or having to step through it with a debugger

>>4
Or you could just take the easy route out and use Lisp.

In a small example like this, the benefits of unit testing over asserts are hard to show.  In full unit tests, you can build up full object instances, etc. and do much more comprehensive behavioral testing of the objects than only asserts would allow (e.g. making sure state variables are updated, say maximum/minimum/count upon enqueue() being called in a priority queue implementation, etc), and the separate test program has the added benefit that testers/QA people don't need to muck around directly in the developer's code, since the test scripts/suite will be isolated.

In my opinion, developers should write at least a minimal set of unit tests for each function/method, and let QA guys (if they're lucky enough to have them) handle trying for complete test coverage.

>>3
int add(int a, int b) {
 if(a==1 && b==1) return 2;
 else if(a==-1 && b==-1) return -2;
 else if(a==-1 && b==1) return 0;
 else if(a==2 && b==3) return 5;
}

TDD is shit.

Already talked about that in post 6 regarding complete test coverage.  And if you checked in code like that, I would first stab you in the face, and then send you to work in the cafeteria.

>>7
If you're a shitty programmer, nope, TDD won't help you.

TDD is fancy talk for "write your test cases first"

It's not a bad idea.

Let someone else write the test cases.

joh joh joh /prog/ is so fresh against /prog/ reddit looks like a rat

Here's how TDD made sense to me:
when you write a function, ideally, you have some definition of what you want it to do before you write it. Here are the inputs, here is what things should be like afterwards. The unit test is just translating that definition into code. This has the benefit of allowing you to actually run your definition, so at any time you can see if your function does what it's supposed to do.

This means you can change things and refactor, and you have a system in place to catch logical errors on top of bugs that your interpreter/compiler would catch. However, it's not foolproof, because your tests have to completely define your function: meaning catch all the edge cases. And this works best for programming in a purely functional style (hence why some people harp on that so much): when you have side effects in your functions, whether your test works might depend on when you run it.

Proof > Test

>>14
http://upload.wikimedia.org/wikipedia/en/f/f5/Principia_Mathematica_theorem_54-43.png

>>15
I happen to have read PM up to page 130 or something, and it is enough to understand the notation. Do you know how remarkably simple this 'theorem' is? It says that if both a and b are '1', but not the same '1', then their union is '2'.

You can think of a = i'x as a being a set of cardinality one. Basically it says that a \cap b = 0 <=> x != y.

Russel thought his work was more important than it really were, that's why he goes through great length of doing things at times, when it isn't necessary.

>>16
Wait for it... JEWS

>>16
<=>
(　≖‿≖)

>>18
(　≖‿≖)

(　≖‿≖)

Before the spam, this thread was far more interesting than anything else posted in the last week.

No, really, everything formerly above this sucked cock and ass.  Both.

lrn2realsoftwareengineering, poseur faggots.

ITT: fagz who have never written more than 50 linez of code.

Fuck me, finally a post about programming.

i have a iq of 128im atletic im fucking kind and im fucking handsome how the fuck could i end being a fucking fach informatiker i mean im not even one im inthe fuckling ausbildung nigger