I guess TDD can be great for parsers.
Why TDD isn't crap
101–110 of 171 posts
Re: Why TDD isn't crap
#102Hi Hillel Wayne (Author), I love your writing style and that you are so carefully articulate about what people say, and reading their arguments charitably! The world needs a lot more of that. This article has an inspirational writing style that I will try to leverage in my own writings. PS maybe put your name at the top of your posts :)
Thank you! I was heavily inspired by Dan Luu's blog (https://danluu.com/), so I'd recommend checking that out too.
Re: Why TDD isn't crap
#103The only thing I disagree with in this article is the leeway given to supposedly legendary programmers who can somehow write bug-free code without tests, specifications, or an inkling of communication with others. First, it's probably not true. Linus Torvalds is not a legendary human being who can write critical systems without a single flaw. He relies on legions of human beings to carefully check and review every li…
> The only thing I disagree with in this article is the leeway given to supposedly legendary programmers who can somehow write bug-free code without tests, specifications, or an inkling of communication with others.
I absolutely agree with your disagreement here.
Re: Why TDD isn't crap
#104Earlier quoted context omitted.
"having test play some part in how the code takes shape" That is exactly the point why I don't like TDD. I mean, there are enough constraints that shape the code, why should something artificial like tests shape it too? With mocking and everything you end up writing code for tests and not code for your problems.
Well, you write code for design flexibility. Testing just forces the issue and helps you explore possible design needs. For example, what if the database query you're using isn't suitable any more? Instead of designing around a User table, you start passing around User records. Then your design is more future proof in case you start getting Users from a service or in-memory cache instead of a database. > ...not code…
[deleted]
Re: Why TDD isn't crap
#105Earlier quoted context omitted.
In most statically typed languages, the bugfixing (usually) takes longer because you need to do many more things each time you refactor. An enterprise Java application doesn't typically pass around the equivalent of a JS object. It passes around Users, Admins, and Guests. But then some features in Admins need to be added to Users without affecting Guests. But Guests inherit from Users, so you have to go back and rest…
I'm beginning to suspect that, in the context of these debates, "most static languages" is a roundabout way of saying, "Java", or other static languages with a similarly anemic type system. Also it's a roundabout way of describing the particular way that Java code tends to be structured. In one that has better support for generics (i.e., reification, contravariance and covariance) and some form of mixin, you generall…
> ...is a roundabout way of saying, "Java", or other static languages with a similarly anemic type system...
I agree. In my experience, it's how the median developer writes code, though. Even in more flexible languages they'll reach for type hierarchies and abstract base classes. I've seen people create these things in languages like Lua and Javascript that don't really need them.
I think TDD-like approaches make the case for other approaches more clear, for what it's worth.
Re: Why TDD isn't crap
#106Earlier quoted context omitted.
In most statically typed languages, the bugfixing (usually) takes longer because you need to do many more things each time you refactor. An enterprise Java application doesn't typically pass around the equivalent of a JS object. It passes around Users, Admins, and Guests. But then some features in Admins need to be added to Users without affecting Guests. But Guests inherit from Users, so you have to go back and rest…
Somewhat disagree - you still have 'types' in JS, but the runtime just sees maps instead of concrete types. The concept is still there, but you won't get an error until runtime if you invalidate the models. At least with static languages the problems are made clear up front and prevent compilation. There are other limitations though, such as not being able to treat static types as a hashset at runtime, which can be g…
The 'types' in JS don't typically include implementation implications as much as they do in more strongly typed languages. If your algorithm is looping through a set of widgets, you just need a container and things that look like widgets. In Java, C++, etc., you often are pulling in a type with baked-in assumptions about logging, DB access, etc.
Re: Why TDD isn't crap
#107The problem with many TDD critiques is that they offer no alternative. The original presentation: https://www.youtube.com/watch?v=DQBf6li1hww is a case in point. Presenter takes what he believes to be TDD's four main points, some of them strawmen, and mocks them. He does make some good points, but here's the problem: he offers no alternative. If you're not writing tests as you go, that you run before every commit (or…
>If you're not writing tests as you go, that you run before every commit (or before you move onto the next thing), then what is your standard for putting code into a production repository?
It seems to me that that would be the same standard that you would otherwise try to write a test for.
Now writing a test isn't necessarily a bad idea, but I think it's important to realise that the test isn't the standard itself, but is itself an implementation.
Re: Why TDD isn't crap
#108Earlier quoted context omitted.
Well, you write code for design flexibility. Testing just forces the issue and helps you explore possible design needs. For example, what if the database query you're using isn't suitable any more? Instead of designing around a User table, you start passing around User records. Then your design is more future proof in case you start getting Users from a service or in-memory cache instead of a database. > ...not code…
This is exactly the problem. In general you should not be writing code for design flexibility. Your code should contain the minimum number of abstractions to satisfy its requirements. If flexibility is a requirement right now then that's ok. Otherwise refactor in the flexibility later. But don't make the code flexible for the sake of tests. It vastly over-complicates it for no benefit. Instead write tests as close to…
> Otherwise refactor in the flexibility later.
I'm saying, with experience, teamwork, communication (including through tests), you'll know when this proposition makes sense or not. It's not universally true that "we'll worry about it later" make sense.
Re: Why TDD isn't crap
#109Earlier quoted context omitted.
Which by definition means your tests are legacy code. It's turtles all the way down. For what it's worth I do think Unit Tests provide value.
The code is the “test” for your tests ;)
The code and the test are probably to some degree based on the same logical construct. If that logical construct is malformed your tests may pass and your code might not work.
Regardless if your code works your tests could still fail, likewise your code could not work and your tests pass so since the tests and code may vary independently if either is buggy I don't see how this can possibly be true.
Re: Why TDD isn't crap
#110Earlier quoted context omitted.
If you use mocks extensively in your tests then you probably aren't getting much of the benefit of TDD. Mocks indicate high coupling so using them is just powering though testing your bad design rather then driving good design via testing.
How do you handle dependencies of the class under test then?
Would love an answer to this question, as well. I've only come up with DI as a long-term mostly win for this problem and it's something that I grapple with in every code base at work, since we have some microservices and other HTTP API layers that we need to interface with and I want to write testable code.