411–420 of 450 posts
Earlier quoted context omitted.
I've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.
It's a very common way to evangelize TDD. Ruby Koans is a tutorial entirely based on that principle.
Earlier quoted context omitted.
Curious. How so? Get a bug report. Write a unit test that reproduces the bug. Fix the bug. The unit test now passes. Check it in. Now its part of your growing regression suite. How is this not "test driven"?
Where's the design? (To me TDD was always championed to help specifically with Design as much as the vague Development . When using the vague Development too loosely you run into a recursive problem because writing tests is itself development so do you use TDD for your tests?) Depending on how seriously you take the step of writing a unit test that reproduces the bug, you may be forced to refactor quite a lot of code…
Earlier quoted context omitted.
Well, that's exactly this case. You would write a test to replicate/prove the bug and then - afterwards write the code to fix the bug, no? So you would write tests first.
But the code containing the bug is already there. The idea of TDD is that you write tests verifying behavior before there is any code.
Earlier quoted context omitted.
Sorry--that was a generic "you" there, not you-specifically. I'm saying that this is something everybody needs to understand because writing state-munging code is intrinsically harder to do correctly. He's not just "splitting the code into two parts", though. He is consciously and specifically defining a core based on functional principles that avoid mutating state (which is harder to measure and reason about). That…
"Functional core, imperative shell" sounds quite dogmatic and not "getting it" is no reason to fear for anyone's code. Just like the OP article argued that TDD can become an all-solving hammer in the eyes of people, so can functional programming. In this particular case I can think of a whole host of applications where the core should definitely not be functional (and, for what it's worth, immutable state is not inhe…
And functional programming has never encouraged mutation of data model objects. Not at any point. Mutation of data model objects is and can be nothing but a side effect of a function. There are cases where you can't not mutate a model, such as when that refers to a system resource (a console, a socket, etc.); those are not your data model. Those are dependencies that your application uses to create instances of your data model and feed them through a set of functional processes. Almost like there's an imperative shell that deals with and controls side effects, wrapped around a core of pure functions that manage stateless transforms based on your business logic...?
ORMs (in the mutating, own-your-object sense like an Active Record model) shouldn't be a thing because they're awful creations that aggressively they encourage bad, muddy code that's harder to test and trace and debug. Once more for emphasis: the second you mutate a data object you have made testing an order of magnitude more difficult and now you have to live with that forever. Active Record requires this. There are places where you may choose to embrace this, but it's a good way to shoot yourself in the foot.
On the other hand, data mappers (Anorm, DataMapper, Slick) live outside of the cleanly tested, no-dependency core (and its data models) and are used to feed objects into your business logic and record the results back to an external data store.
If you aren't using plain old objects to encapsulate your data, you're asking for it.
Earlier quoted context omitted.
Playing devil's advocate here: I'd say that algorithm design (Which is what a sudoku solver is) is a bad fit for TDD. However, I'd argue that most problems in commercial coding are of a more engineering/architectural type of nature. Here, outside-in TDD has it's place. Outside-in TDD can help you tackle problems that seem enormous, and slowly but steadily break them into smaller components.
I find TDD useless as a way of poking at problems I don't actually know how to solve (as Jeffries found with Sudoku), in the way and slowing down when writing large new systems, and excellent when bug-fixing maintenance. Test Driven Debugging!
I do not design a sorting algorithm from scratch (without consulting any of the literature on writing sort) - I could but the result would probably be a variation of bubble sort. However I stand on the shoulders of giants. That means I already know bucket sort, quick sort, insertion sort, bogo sort (and several more that were covered in CS203). I have never encountered a situation in the real world where calling whatever sort is built into my language is not good enough.
Most problems are variations of take some data, do a little math, and [save for latter use, present to the user, or change some physical control]
Earlier quoted context omitted.
> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. Actually, there is ; providing the difficulty is algorithmic. Take "sort", for example. // test code assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5])) // production code int[] mySort(int[] list) { // TODO: implement a sorting algorithm here. } Any programmer could write a fairly good test suite for "sort". How…
> "Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation." I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.
The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.
The idea only exists as a straw man for those trying to attack TDD.
TDD doesn't ensure there are no bugs. TDD ensures that everything you can think of that can go wrong does not, even as you think of new ways something could go wrong and fix that.
I was in one job a few years back without tests. We had a case where someone got a bug which was easy to fix, but they didn't realize their fix broke something else. Then we released and got the bug report which was fixed by reverting back to the original bug - we went through 3 rounds (over 6 years - a different contractor on the bug each time so who didn't realize what was going on) before someone realized what was happening and fixed both bugs.
Earlier quoted context omitted.
My former lab tried to use TDD. I've come to the impression that it's not the right approach for science / prototyping and just bogs you down. I don't think that science should eschew testing completely- I just think that something like your "redundant random generation testing" is more in line with what needs to go on. The trickier issue is changing your lab culture so that it actually understands the need to run te…
This is funny, because as a consultant, I think to myself "TDD really doesn't work for me, because I've got so many 3rd-party dependencies that I have to mock out in my tests (which often makes unit tests seem more like a test of your mocks than of your actual application); TDD must really be best for researchy things where they don't have to deal with those problems".
As a bonus if there is a bug in the 3rd party code I'll find it before we go to production. My boss doesn't want me to point fingers and some 3rd party code when we are losing millions of dollars because of a software bug: he doesn't want to lose those millions of dollars in the first place!
Earlier quoted context omitted.
Research and startups are on the west coast, government and finance on the east coast. Q.E.D.
Research is all over the place. East coast has MIT and Harvard.
It's interesting what happens when you look at rankings of engineering programs, especially at the grad level. You start to see more large state institutions, as well as more technical institutions, with a heavier concentration in the mid west or west coast.
The ivies are hardly missing in action, especially Cornell (should probably also say Columbia) but Texas, Washington, many UC campuses, certainly Michigan... I'd probably put all these, certainly at the graduate engineering level, at or above the ivies. And the ivy that really seems to be a heavy hitter here, Cornell, again shows how much things have shuffled up once you go to engineering.