Viewing profile — hitchstory

>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. Doe…

>But the before-test is strictly negative I actually did this the other day on a piece of code. I was feeling a bit lazy. I didn't write the test and I figured that making the type…

>I've often figured out late in the game how to make something a compile time failure rather than a runtime one This is actually a good (albeit somewhat niche) reason to not write …

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…

A shit test written before writing the code is still a shit test. Mimetic tests arent be any better written after the code either. If I had to choose between 1) always writing spec…

>As for what is gained, try this spelling: test driven development adds load to your interfaces at a time when you know the least about the problem you are trying to solve If Im wr…

Ive had this experience with team-specific vocab where certain terms organically end up having terms with two or more conflicting meanings and it was horrendous. It led to all sort…

You need the final implementation before taking the final snapshot but you can write the entire test up front (given/when). The snapshot artefact is generated not written (often in…

Well ok...but then what kind of code doesnt it fit well? Almost every user story I follow in production code follows the form of given/when/then scenario which can always be transf…

Ive done this too. The exercise wasnt arrays (Im militant about only setting very realistic tasks). My task required modifying existing production-like code and tests. My hope was …

Not necessarily. On plenty of projects I have done 100% TDD and never written a single low level unit test. The type of test is, in my mind, a completely different topic to red-gre…

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…

>Sometimes you need the unit before you can unit test. Right. In those situations I TDD with an e2e or integration test. I dont get why youd restrict yourself to doing TDD with jus…

I hate coding fundamentalism with a passion too. The only thing I get really religious about in coding is the importance of trade offs. The cost/benefit of writing a test before ju…

Not the only value though. Red-green-refactor can also provides live feedback about whether your code is behaving correctly as you write it. Requiring the test before writing the c…

I still find the skepticism around TDD weird. Except for a few pretty niche scenarios (e.g. it's experimental code or manual testing is cheaper for some obscure reason) i dont real…

>my understanding of the problem only really forms through writing code and seeing what approaches work. Unless you are working with a new/untested technology or approach (i.e. you…

Depends upon the ORM. Like all frameworks, a really good one is a significant productivity boost while a bad one is faworse than none at all.

Jane logs in, enters her DOB which is 11/5/1998, does Y the result of which is Z. Where X, Y and Z are very specific. These example scenarios work well as a communication medium fo…

>something about the layers below Absolutely. They were tests over a big ball of mud in a company I had joined recently. This is, I think, the only good way to work with what is pr…

By faking the DB I meant either running a local, prefilled fake DB server for every test or faking the interface to the DB. Which one you should do depends on how complex your inte…

If you're working with a big ball of mud, I find that the best approach is to immediately start doing TDD with hermetic end to end tests. Hermetic = could run just fine on their ow…

The other extreme of this is: * Bad abstractions which just stick around forever. There are some examples of this in UNIX which would never be invented in the way they are today bu…

>However, very few developers follow this approach religiously I do it pretty religiously. There are 3 exceptions: 1) I'm doing a spike (i.e. what author calls exploratory code) in…

>I believe you other than tests being specifications If you're not, that suggests you're not doing them right which in turn suggests why you might have an issue with them...