hitchstory

9 ms·

1.
by hitchstory 2y ago
>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 yo
2.
by hitchstory 2y ago
>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 checker catch it was enough. I still didn't wr
3.
by hitchstory 2y ago
>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 a test scenario at all , but it's still not a
4.
by hitchstory 2y ago
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 consum
5.
by hitchstory 2y ago
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 specification-linked tests that make as few architectural assump
6.
by hitchstory 2y ago
>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 writing a single line of production code I should know as m
7.
by hitchstory 2y ago
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 sorts of bugs, misunderstandings and even arguments. Even worse,
8.
by hitchstory 2y ago
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 a different file entirely), so Id argue it still fit
9.
by hitchstory 2y ago
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 transformed into a test of some kind (e2e, integration,
10.
by hitchstory 2y ago
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 always that the candidates would do TDD where it seemed simp
11.
by hitchstory 2y ago
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-green-refactor and for the decision about which one to write I
12.
by hitchstory 2y ago
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 te
13.
by hitchstory 2y ago
>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 just with low level unit tests.
14.
by hitchstory 2y ago
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 just consistently exceeded doing it after for me. Same
15.
by hitchstory 2y ago
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 code also ensures you dont forget to write a test to match th
16.
by hitchstory 2y ago
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 really see the point of not doing it. I especially dont see
17.
by hitchstory 2y ago
>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 need a spike), the same kind of understanding shoul
18.
by hitchstory 2y ago
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.
19.
by hitchstory 2y ago
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 for discussing intended program behavior as well as
20.
by hitchstory 2y ago
>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 probably (unfortunately) the most common type of real world
21.
by hitchstory 2y ago
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 interactions with the DB are. Some apps (e.g. CRUD) have half
22.
by hitchstory 2y ago
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 own if run on a freshly installed OS that is cut off from
23.
by hitchstory 2y ago
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 but nonetheless aren't going anywhere (e.g. signal handli
24.
by hitchstory 2y ago
>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 which case, probably this code is getting disposed
25.
by hitchstory 2y ago
>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...
26.
by hitchstory 2y ago
When I do TDD (virtually every time i write a line of code) each test scenario isnt just a way to verify that the code is working, it's also a specification - often for a previously unconsidered edge case. Throwing away the test means
27.
by hitchstory 2y ago
I think the premise is correct and I think you are disagreeing with it. Yes, the pyramid was set out as a goal in its original incarnation. That was deeply wrong. The shape ought to be emergent and determined by the nature of the app being
28.
by hitchstory 2y ago
Id say if you think tests and types are doing the same thing in the same way you are badly abusing at least one of them. One attacks the problem of bugs from the bottom up and the other from the top down. They both have diminishing return
29.
by hitchstory 2y ago
You can get 100% coverage by focusing on testing the public API too. These two things are completely orthogonal.
30.
by hitchstory 2y ago
Unit tests for complex logical or algorithmic code with simple interfaces. Hermetic end to end tests for the rest.

More ›