WTH is with Test-Driven Development?

Post Reply New Topic

The most important thing for me would be to figure out how to find the high-yield cases and really avoid what looks great to someone who'd say 'the more tests the better' but never fails because I work for a small company and the choices if I'm doing a lot of testing is either a) hurt their bottom line or b) work all kinds of extra hours off-book. I was doing the later when I had to on previous projects but this is where I really need to know, similarly in C# with something like xUnit, how many tests would simply be 'Yep, C# hasn't had any radical changes or overhauls' and exclude them (my guess is this is what happens if you get 'too' granular).

The other thing about Angular - it doesn't seem very often like something works and then just doesn't. A lot of the issues, particularly with dates (.getTime() is not a function - if you forget to do = new Date(x)), it's not subtle when all of the downstream events that are supposed to happen don't. There's also maybe timing issues when a client has asked for a lot of automated convenience and differences in system speed but a lot of those would be integration testing.

A side question since you're in that environment (not related to the overall thread). I do have one practice where I sometimes debate whether there's a better or at least more elegant way to deal with this. This is where I need a before and after value on a property to then compare against each other and I've noticed, I think it's an inheritance / delegation issue, that if you take reading of a value (lets say it's two numbers, the incoming event is 12, the original is 1), you say let x = original, then further down original = incoming, and then - if left like that, x = incoming (x changes to 12 because its value stayed tethered to original) even though it happens later in the chain and particularly this seems odd if the equivalence is tested in an if statement that's wrapped around the area where original = incoming is implemented. I made a simple deepCopy() function to hide a JSON.parse(JSON.stringify(x)), it works but it instinctively feels like it's cutting cross-grain with the system logic.


I think the trouble is also just in really bad / dogmatic rollout. Like I'd love to see if DHH and other people like him (who are half-approving/half-disapproving) have a lighter weight version that they recommend. I'd get the sense that the dogmatists would hate the luke-warm because it gives people more of what the wanted and relatively mutes them but for this to really work properly there has to be a practical way of implementing it or some place where you can find good philosophic framing of what sorts of things end up being high-yield targets (and obviously not needing to test get and set).

@techstepgenr8tion regarding your question, you would have to provide more detail before I could answer.

Good point.

I actually tried Stackblitzing it out a few times and the issue I was looking at didn't come up (it's more one of those where if it does come up I deep copy my way out of it). I know it involves storing values in component-level properties, in some cases that property may be subscribed to an observable, but the most recent case I ran into with it was with dates but it's not a clean example.

If I do find a pristine example one of these days soon I'll post it.

For the uninitiated, Test-Driven Development is like breeding "generic" field mice before starting the "Better Mousetrap" project and using the generic mice to test the effectiveness of the mousetrap at every stage of development.

This is opposed to the idea of building a mousetrap, baiting it, and setting it out to see if it captures any mice.

I would use a different example and @techstepgenr8tion will agree with me.

Suppose you're using Agile methodology to build a car. In this Sprint, you will add the brakes. Your unit test is to drive the car full speed towards a wall, to demonstrate that brakes keep you safe in that situation. TDD demands that you first perform that test BEFORE adding the brakes.

If it's a nerf wall that won't do structural damage sure.

I think what's bothered me more about this research than the principles is that if it's so important that everyone does it - why is finding out more information about how to get started (even on places like Udemy) so non-demonstrative that you really have to either a) figure it out yourself or b) ... wait for it... go learn from someone who can teach you and get slotted in under them in their fiefdom.

For that reason I really want to take a shot now at learning it just so I don't find myself in a place where some ambitious middle-man has me at a disadvantage.

It's probably been way too long but I just linked my GitHub to CodeWars and I'm starting to play around with their katas (there are some really cool things I'm seeing with LINQ over there, hoping to do more in typescript today). I'm thinking maybe the more I practice with those the more I'll get some idea of how I might build a project starting with code katas, and really the katas themselves are like a very non-granular (not Bob Martin approved) red-green-refactor-ish thing, but it's provided on the level of the kata rather than real TDD where any of these would be several or more red-green-refactor cycles. Regardless I think their katas will be a good place to inform my intuitions on how I would need to do it in order to make it work in my set and setting (or if I end up needing a new job - ie. enough bad business decisions add up - I won't get strong-armed at my next job over this stuff).

I have experienced this myself.

I have a theory how Agile got started. A manager walked through an office where programmers were working. He saw all these people quietly glued to their workstations and became upset, so he thought up Agile so that now when he visits the development department he sees pairs and clusters of people animatedly discussing User Stories and relatively few actually coding, and even the latter are sitting side-by-side. In other words, programming became a much more neurotypical activity and all was once again right in the world.

I'm sure something like that does happen regularly.

The clue to me though is that Agile and TDD make sense for plug-and-play groups, like loosely connected professionals on LinkedIn doing various projects, working as free agents, and it sets a minimum spec for work environments where quite often the ability, knowledge, etc. of other coders can sometimes be an unknown so it's a great way to standardize the process - fine, certain situations it fits. To say though that if someone's not TDD they're not a professional - that's where its clarified that people are jumping on this for completely different ends including reasons similar to those you just mentioned.

Not only does TDD allow for gathering before-and-after data, it is also loads of fun to make test vehicles smash into things!