[OT] I got a JOB!!!

Excellent! Congrats... (maybe take off that tag line that says you are looking for work.:^)

George H.

Seek and yee shall find. Basic law of the universe.

Good luck! But keep your options open.

Good luck and welcome back to the dark side

I need to, yes. It was never on in this computer.

Software Designer 5? Sounds a little like being in Sector 7-G?

Time Division Duplex?

"Really Senior Embedded Guy".

Test Driven Design.

Be prepared to meet some people that believe X works /because/ all the unit tests for X are passed and the console shows a green light.

Usually they have never been introduced to the concept that "you can't test quality into a product". Unit tests developed as part of TDD are highly beneficial, but are not sufficient.

But I'm sure you know that!

Good luck. I don't have any job and got a traffic ticket for $238 plus $54 to attend traffic school. I plan to fight the case since the signs are not properly posted. If I lose, I will ask for community service and tell the court I have no money and would like to pick up trash on the roads. The city pays $10 an hour for picking up trash. Or, I might get an easier job working in a senior centor. Time will tell. I made an illegal left turn where the signs are hard to see. There is a picture here::

Well, yes. The two main good things about TDD for me is that it makes me think early about how something really should work, and there are finer- grained tests to make sure that if I did something really dumbass it gets caught.

Even with TDD, I still find errors, so I don't live under the delusion that you can test in quality.

Yea verily!!

And now it's not on this one, either. And PAN can stop complaining about my 4-line tag.

The other dysfunctional aspect of unit tests is that, while they are very useful when making incremental improvements during design, they can be a real impediment in a few months/years time. The problem is that over time people forget which tests demonstrate required properties, and which are merely ensuring behaviour of implementation artifacts. At that point people are afraid to make changes that break tests, even if the tests are unimportant. At that point the codebase has become ossified.

Classic anti-patterns warning of that: unit tests on getters/setters, and/or changing visibility solely to enable unit tests.

That's an interesting point. I haven't been using TDD long enough for that to be an issue. Good to know!

TDD works where it gives you *another way* to state your expectations. Testing getter/setters never says more about the getter/setter than is said by their declaration, so the tests have zero value.

The important thing is to say "how else can I state this requirement?". If you're using truly succinct code, such as strongly-typed Haskell, there often is simply *no other way* to describe the expected behavior. That's why FP aficionados scoff at TDD zealots. Programming with strong types is always better than using TDD.

Clifford Heath.

Sounds great. When I was looking for work when I got out of college, I had an offer to work at a little company called Motion Message. They did LED message displays, that was in 87. I got another offer and I declined their offer. But I thought it was a neat idea at the time.

Cheers

America, Great Again!

Er, that's not TDD, that is Unit Tests. To be overly simplistic, TDD is a strategy for generating Unit Tests.

Strong typing is very beneficial, but is completely insufficient. As one of an infinite number of trivial examples, consider testing for X>Y when you should be testing for Y>X.

The simple point to bear in mind is that the results of TDD are only as good as the quality of the tests. Test the wrong/unimportant thing, or don't test important behaviour, and the outcome can be "suboptimal".

That's not a difficult point (to put it mildly!), but it is horrifying how it is ignored by zealots and/or not appreciated by inexperienced.

The best defense is, to quote one of the two mottoes worth a damn, "Think". No change there, then!

Good code, in the best languages, can be read like a spec. When that happens, your code and your test is the same thing, expressed in the same way. Nothing is achieved by writing it twice.

If you got the code wrong, you'll get the test wrong too. That what I mean by "another way to describe" expected behaviour.

In article , snipped-for-privacy@blueyonder.co.uk says... .......

The Titanic sank but I bet nearly all the individual parts past their unit tests.

Or the video I saw on Dev Humor a while back of sliding door and bolt to lock door fixed wrong way. Each part past its unit tests.