WTH is with Test-Driven Development?

Post Reply New Topic

Asking because I'm trying to approach the issue and the environment seems insane.

I'm all about self-testing code, I don't think it needs religion.

What doesn't make sense to me about the dogma - you've gotta be in an unusual situation to red, green, refactor all of your utility functions to then build the code that it will be riding on while never writing a single line of code in the program without a failing test first. I did at least watch one really good discussion (between DHH, Martin Fowler, and Kent Beck) where they were talking about it in practical use terms but then I see Bob Martin debating Jim Coplien and really sounding more like an HR director than a programmer (follow the dogma to the T or you should be flipping burgers).

If you're in a company where you're the internal programmer and your employment is supporting that code base - then you might not be under the stress of direct billable hours and you could write four lines of tests for every normal line of code. If you're on a project team that's putting together a product that's going to be distributed - it's okay there because you're not on the billable hours model - you're on a project where the real money comes with distribution of the end product (again more flexibility).

I'd feel better if the concept actually delivered what it's supposed to but... unit tests are good for making sure utility and other small functions do what they're supposed to do. Acceptance/behavior testing is probably the thing I see as making the most sense because you're isolating your business logic and making sure that the places where everything gets done is reliable. Sometimes unit tests make sense to me other times when it comes down to it, so much of what could or would go wrong in some thing like hiding a linq list filter behind a function would be found by the linter (even if a new version of C# came out that would fundamentally change the meaning of some piece of that).

What I've been trying to figure out though - I'm at a company that's on the billable hours model (where so much of it is either billing or not billing based on whether or not we think the client will give pushback, even if the new hours were based on them changing their minds on something). Ideally I'd love to be able to do my own tests as I do now, plug something into them, and get my red and green on the other side of that (in some senses test-last but really just dovetail my own tests with that sort of output).


I also have to wonder if I'm working in an industry where more people are realizing that we've built our own obstacles in certain ways and when we reach a wrong turn we make sure to double-down on it. It has to be profitable in the work hours sense to work financially and if it isn't people just won't do it.

Ok, I'm far from an expert in any of this and perhaps I haven't understood you, but isn't test-driven development a sort of natural response to the increasing complexity of software?

I mean, any large piece of software has so many people working on it that there has to be some sort of standardisation of process, if you're going to be efficient?

And when you're encapsulating everything, doesn't it make sense to have a very clear idea of the results any piece of code should produce before you start writing it?

Isn't that what the test code does?

I've never worked in a test-driven development environement. I'm not even a coder so I'm not saying you're wrong at all, but just that I don't quite get the objection.

You say it's like a religion. I get that. I sometimes think we have religion because people with power tend to trust their own behaviour but don't trust the behaviour of others, so they provide them with some rules to follow. I can see that test-driven development is a bit like that, but I struggle to see the alternative.

My read of it is similar to that, ie. that it makes the most sense when you either have big teams working on projects and standardization between components and quick ways to check if everything is working are needed.

I'm in a situation where I work by myself and have to brainstorm the software from start to finish, and I have to additionally brainstorm it at an hourly rate that the client won't throw back at my boss and simply say 'No, I'm not paying it' (also our fault for taking on customers who think what we do is akin to magic and don't have any grasp of what kinds of problems optimizing UI for conveniences causes) so we have to eat costs that we think the client either wouldn't psychologically 'get' or costs that we think they could even pass themselves off as psychologically not getting in which case - honest or dishonest - the result is the same.

I think of when I had my first accounting internship when I got out of college, had a really mangled mom and pop operation that I went to work for, wouldn't train at all, and when I asked about closing knowledge gaps they showed me something like a 10' x 10' wall of books and said 'start reading when you can', which in practical terms they should fire me by the time I've read a few hundred pages of something because it's time I wasn't generating any profit.

I think what irritates me here is that there has to be a way of getting the benefits of the red/green output without making it so that your boss can't pay your salary. My best guess is just do the 'test last' thing and add tests when you see critical modules coming up and add the red/green tests to your arsenal of other tools like self-auditing portions of the code that force failure if the results don't conform to certain rules (this is really my favorite way to go because what testing you do as a developer in that case won't let your code fail silently or worse, send garbage back to SQL or some consumer credit bureau).



I'm sure that's what it is.

The thing I hate though about that kind of climate, aside from HR people only processing buzz-words, is you'll have more mediocre sorts who'll treat you like you're a glue-sniffing credit card stealing screw up if you didn't come out of the womb doing thing precisely the way they do to the last letter. I sometimes really get concerned that thinking from first principles could be the death of me or my ability to pay my bills if I can't find some really robust ways of defending myself against that mentality.

I can certainly see how it would be a very restrictive way to work, if you're more of a free-thinker.

But I can also see why a business would implement it as a working practice.

I guess it comes down to whether as a business you feel you have the headroom to allow your developers to work in their own way and hopefully come up with some innovative stuff that might not have been done under test-driven development.

Or whether you're just trying to deliver for your clients as quickly and reliably as possible.

But from a developers perspective, yeah, sounds like it denies you much opportunity to experiment. And probably takes a lot of the fun out of coding.

Where I work it's pretty flexible, and TBH they threw me in to projects that would have sunk them - without knowing half of what I needed to know (had to make up the difference on my health), so I don't think risk aversion's going to be much of a driving concern.

What I worry about more is trying to get my next job as a coder if (really when) it's realized that we can't turn a profit with our business model and when we quite likely have to go somewhere else. I suppose in that context the thing I really should do is practice with xUnit a fair amount, do some acceptance testing (Specflow, etc.), and be able to say in an interview that I at least know how. What I'll similarly want to do is ask as many sharp questions of my interviewer as I can to see what their views on testing are. Mainly I'm fine with hard work, I'm much less okay with being burned as a fuel rod for someone else's ambitions who could care less if my parents have to bury me from work-related health problems.

Do you have to work for someone else?

I experienced some of the same sort of restrictions in my career. I went freelance which suits me better. I mean, it has downsides but on balance it works better for me. At least all the work you put in is for yourself, you don't feel so exploited. I'm not in tech so the reality of doing this may not be the same.

I guess a couple questions on that:

1) How do you line up jobs unless it's people you already know?
2) How do you assure that your clients don't stiff you on payment?

Well those are the hard bits of being freelance. No easy answers.

1) All my work has come from word of mouth and I built up over years before I had enough to ditch my salaried job - I try to market myself but it's not a strength and has never worked for me. But people do get clients through marketing, that's the normal way in fact.

2)If it's a new client I always ask for 50% up front, 50% on delivery. The sort of client who would consider stiffing you will never go for that deal. And if it does happen (never has for me) you've still got 50%. You can mitigate against this stuff by going overboard with the detail when you're agreeing terms with the client. Nail down exactly what you'll be supplying so it's inarguable that you've delivered.

Another question - do you look 'youthful', like in a way that draws negative attention and gives people the wrong idea about your capacities or ability to defend yourself?

I need to make some of these decisions based on what are immutable issues (I've at least grown a full beard, Covid seems to have relaxed restrictions on that, but still have a bit of that Christian milk-sop glow).

Last time I was heavily involved in development we used test coverage kind of as part of specs at the start. I would write majority of test coverage and it was handed out to coders who were billed hourly for implementing this stuff, they normally didn't write tests themselves unless something changed in specs. Successful build and passing all tests was a requirement for a feature branch to be merged into the main.

And then final unit tests were used in our CI setup when stuff was deployed to production.

We didn't use it as a formality, it was a very practical necessity savings us a lot of time.

Yes, I think working for an agency as a developer on hourly basis is not great if you are a creative coder and want your job to be fulfilling. Sometimes it works, but in the end you are not working on a product your employers sells, your time is a product your employer sells. Mediocre work generates maximum profit. You are not going to be rewarded for thinking of a quick solution or for putting more effort into more elegant and maintainable code, building more scalable architecture.

You are better off working for a company developing it's own product, interested in quality and better/faster solutions and maintainable code base and infrastructure, instead of trying to bill as many hours as possible while keeping a client.

Pretty sure I don't look youthful. My hair started falling out at 16 and was pretty much gone by 23 so I've always felt like I look like an old man! Can't grow a full beard, don't have the hair density, but I'm never clean shaven.

I don't really know how people perceive me. I'm quite a big guy, 6'1, slouchy and barrel-chested. So with the bald head and a perma-scowl on my face, because I'm squinting from light sensitivity, I may well look to a stranger like someone who can defend themselves, or may even be aggressive. It's not accurate though, I'm bookish and weedy!

I don't have to meet people face to face much in my work, which suits me just fine, so I don't think it has much bearing on my ability to get clients.

Would I be wrong in thinking that people expect techy types to skew younger? There's the computer whizz-kid trope right? When I learn tech stuff I'm always learning from some snotty-nose 12-year-old youtuber who knows more about computers than I ever will! Perhaps it's not such a problem?

There is definitely a pattern of taking advantage of young naive but capable coders. Less likely to happen if there is any sign that you are an old bird.

Easiest practical solution - use platform offering escrow service. Third party would hold your money until your client approves your work. It will filter out dudes who have no intention to pay in the first place. Then to stiff you your client would need to ask for a refund in theory there would be dispute, he would need to prove you didn't do the work. In reality client can call to their bank or card issuer and get a refund any time, but still psychologically this is actively doing something compared to just ghosting you.

That's a really good idea.

Yeah, to go independent I'd have to find the benefits of having a corporation at my back insuring payment - just without working for one. If that's a common thing that would probably be the best rout for me to go.


What's worse, you can have clients to dominate vendors through (most likely strategic/engineered) belligerence and incompetence. It's sort of the 'We don't understand what you're doing, we barely understand what we need (and you'll be rewriting most of your code several times over - for free because we shouldn't have to pay for that as ther'es no deliverable for changes), but we're the customer - it's our money, and you're going to have to run like hell - 24/7 - to prove you aren't a complete and total screwup'. I suppose part of filtering those people out is actually interviewing them in some sense to see what it is they're looking for and if you get loony / entitled boomer vibes just politely decline.

I feel I must comment on the subject line although the thread has veered into other topics.

So I have officially been employed as a programmer of some sort since 1980. I developed an interest in Java in the latter half of the 90s and have written Java code under various circumstances since then more or less continuously. I currently develop in Angular which means most of the procedural (as opposed to declarative) code I write is in TypeScript (which is a superset of JavaScript). This is a gross oversimplification of what I've spent the last quarter-century or so doing, but it's probably still too much information for most people. BTW I'll be 70 in less than a year, and although the people I work with know I'm old, I imagine most don't suspect I'm quite THAT old, or at least they never say anything to suggest I'm expected to retire anytime soon. The Pandemic may have played a role because nobody interacts with me in person anymore.

So what I wanted to say is I have quite frankly never done TDD as part of my workday, except possibly as some sort of training-related exercise. What's more, I've never worked with a team that was doing it. When I've read articles on the topic, I've seen nothing that I recognize as "real-world". In my current position we are required to write unit tests that cover a certain percentage of LOC or branches, but these are always written after the code itself was written.

I happen to think I'm a good programmer. I sit down and write code that passes the Acceptance Criteria, maintaining a respectable "velocity". I correct defects that testers have identified, either due to mistakes in my own code or that written by others. I also sometimes help less experienced programmers who've gotten "stuck". Somehow I can usually figure out what it is they need to do to get past their problem, despite not having deeply familiarized myself with the requirements they've been given.

I was first exposed to Extreme Programming as a concept in 1999, which includes TDD, Pair Programming, and I forget what other practices I've never felt any desire to adopt. I spent most of the 2000s working in the Financial Services industry and the last decade as a contractor to civilian government agencies, and like I said before I've never found myself part of a team that practiced TDD. On occasion, people have talked about how we really OUGHT to be doing that, but it never happens. Most of what I've implemented over this period of time has gone into Production with few if any defects discovered in Production. When that didn't happen, it has mostly been because the requirements weren't rigorously stipulated at the start. I have experienced the "let's build something sort of like this and see how it turns out" sort of thing and have become especially sensitive to the possibility of that happening, which can happen when some people see an opportunity to make money and have the understanding their chance of getting that money improves with how soon they can implement whatever it is the customer thinks they want. I don't see how TDD can remedy that problem although it might give some people a false sense of confidence that they're doing a good job.

My current project benefits greatly from automated testing. I won't go into detail about automated testing but I'll say that in practice it's way more effective at catching functional errors early in the development process than TDD could ever do. We have a dedicated person doing this and he also has a very good grasp of the requirements. How could you lose?

So what I find least enjoyable about a career as a programmer is that throughout your career you are told that the way you do your job is wrong and unless you adopt a diametrically opposed way of doing it then you can't claim to be a professional. This is largely why I discouraged my son from pursuing a career in software development. Instead, he's a surgeon and I doubt the management where he works ever try to tell him to change how he does his job.

Nevertheless there's a Mafia out there who seem able to bully anybody who publicly questions the dogma of TDD. If you doubt me, try doing it on r/softwaredevelopment. They will cite all sorts of "benefits" but have yet to offer any concrete proof of achieving a better result. I will point out one observation though, that although TDD was developed by an American, it seems that programmers in Europe are more likely to practice it. From my experience, Europeans take a more "academic" approach to programming and tend to spend more time at University before accepting full-time employment, so it comes naturally for them to do things according to some textbook — probably due to having spent years being told how by somebody with a Doctorate. OTOH I've been told by Europeans that anybody with a technical education including Engineering or Computer Science who hasn't "advanced" to management or some other "non-technical" job past age 40 has failed in their career. Makes me wonder how they get anything done.

I'm actually very well versed on that. What I've been doing for the last several years is writing Angular front ends with .Net Core backends. I have to admit, when I tried Jasmine I hated it, Jest looks a lot better and I'm thinking I might try incorporating that for client-side testing.


Same, I don't think I have yet to date run into a problem that I couldn't work around. The worst of that tends to be stuff that's black-boxed off by 3rd parties (I had a combobox that I had to beat on for five or six hours yesterday because I needed the actual selection and 'Enter' key behavior to do different things, the preventDefault() wasn't working for that case, and almost every solution I thought up had a way that the vendor had blocked me).


If I wanted to say something really crass or unpolished about it (which I will because I don't care to filter myself on the matter) - I can't help but think this is social climbers trying to bring Darwinian evolution to the field. It's something like the inverse of talent and it's people who want to force everyone into a game they rule because it's power and power's great for those who love it. It's a bit like 'If they can and you can't - take out their knees'. IMHO it's the death of technological progress and it goes after anything that's getting 'hot' in terms of status.

I admire your enthusiasm for learning more about unit testing in Angular. What we do is just the minimum required to get the "isCreated" assertion (for component) to pass in the test that the Angular CLI automatically generates. I actually created an article on Confluence giving suggestions as to how to do this. I think very few people at the large govt. agency at which I am a contractor, either contractor or employee, have gone much further. I'm not opposed to learning more but at this stage in my career I don't think it is a priority for me unless somebody in authority demands that I do it.