Hacker News Reader

Comment by hitchstory | Hacker News Reader

I usually start with a basic e2e that tests the most minimal happy path possible. It makes no assumptions about architecture or anything else.

You don't need something to work with to write it. You can, by definition, write an e2e test against an app that doesnt exist.

This test isnt special as far as TDD is concerned - red-green-refactor works the same way.

Im sensing a pattern in the answers to my question though. I keep getting "well, if you assume TDD is only done with low level unit tests..."

View on HN

> Im sensing a pattern in the answers to my question though. I keep getting "well, if you assume TDD is only done with low level unit tests..."

Completely wrong.

Even with your example, there's an initial exploratory stage where you're still figuring out the interface that the tests would use. I, personally, am not capable of using something that doesn't exist. I have to make that initial version first before I can use it in a test.

Quick edit aside: This is also why I rarely work top-down or bottom-up, I work mostly throughline - following the data flow and jumping up and down the abstraction stack as needed.

Im not sure quite why you feel you always need to write code before sussing out what an API or UI should look like but it seems like a very expensive habit to me.

What happens when you then show it to stakeholders (e.g. other teams consuming your API, customers or UX people) or and they tell you to change it again?

Rewrite everything again?

Thats gonna be reaaaaaaaalllly labor intensive and could damage your code base too.

Im equally perplexed about why people dont try to build top down. It's one of those few things in programming that always makes sense regardless of circumstance.

If Izkata is anything like me they write code as part of their exploratory design process with no intention of showing it to anyone else until they've iterated their way to a design that they like.

> What happens when you then show it to stakeholders (e.g. other teams consuming your API, customers or UX people) or and they tell you to change it again?

> Rewrite everything again?

> Thats gonna be reaaaaaaaalllly labor intensive and could damage your code base too.

Why would I do that? Only the thing they have issue with would need to be changed, it wouldn't take any longer than another way of doing it.

You seem to have forgotten what I said, something needs to exist for me to work with. Well, in this "stakeholders want something changed", something exists. It's not a rewrite from scratch.

>Why would I do that?

If you change the spec (e.g. changing the contract on a REST API), you will probably need to consult to make sure it aligns with everybody's expectations. Does the team calling it even have the customer ID you've just decided to require on, say, this new endpoint?

>You seem to have forgotten what I said, something needs to exist for me to work with.

No. I'm assuming here that a code base exists and that you are mostly (if not 100%) familiar with it.

So what's the problem? You seem to have gone back on the part I quoted in my previous comment.

Reply on news.ycombinator.com