4 ms·

I will be a little contrarian maybe but I don't really start with tests. The rationale being that until the API is fixed, I don't want to have to adapt the tes

by aatd86 4y ago

I will be a little contrarian maybe but I don't really start with tests. The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time.

bobleeswagger 4y ago
I don't get the obsession with TDD. Maybe it's because I have been in the BI/DE space for awhile, but nothing is defined well enough to justify TDD in the first place. Everything is hobbled together and functional integration tests are much more important. Unit tests aren't going to catch when my CF stacks are broken. Good dev tools and architectural design are much more important in my experience. I totally understand where TDD shines. When you have a well defined problem to solve, unit tests are the definition itself, and the business logic therein.
naasking 4y ago
> The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time. The rationale behind test-first is that you won't know what the API should look like until you try writing some sample client code that uses your provisional API to access some data. So why not make those tests, iron out the kinks in your API and have a few functional tests at the end of it; two birds, one stone.
- aatd86 4y ago
  Still makes more sense to go API first then unit tests rather than the reverse to me. Since an API is a composition of multiple parts that can be tested (the unit in unit testing), it only makes sense to create these tests once the relations between these parts/units are well-established. That doesn't have to always be after the API is completely done of course. Some internal functionalities are likely to be immutable. They can be tested quite early in the iteration timeline.
  - naasking 4y ago
    We're not really talking about unit tests though, we're talking test-first. They don't have to be unit tests, which is why I described writing sample client code because that's what you need to do to anyway to design your API.
    - aatd86 4y ago
      Hum... Usually TDD is associated with unit tests and the article even mentions "unit tests" in its title... What you describe however seems closer to integration/system testing which is one approach I and other people in this thread also tend to favor. But I've been writing UI code predominantly so I am biased here as unit testing has lower value.

by aatd86 4y ago

I will be a little contrarian maybe but I don't really start with tests. The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time.

bobleeswagger 4y ago

I don't get the obsession with TDD. Maybe it's because I have been in the BI/DE space for awhile, but nothing is defined well enough to justify TDD in the first place. Everything is hobbled together and functional integration tests are much more important. Unit tests aren't going to catch when my CF stacks are broken. Good dev tools and architectural design are much more important in my experience. I totally understand where TDD shines. When you have a well defined problem to solve, unit tests are the definition itself, and the business logic therein.

naasking 4y ago

> The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time. The rationale behind test-first is that you won't know what the API should look like until you try writing some sample client code that uses your provisional API to access some data. So why not make those tests, iron out the kinks in your API and have a few functional tests at the end of it; two birds, one stone.

aatd86 4y ago
Still makes more sense to go API first then unit tests rather than the reverse to me. Since an API is a composition of multiple parts that can be tested (the unit in unit testing), it only makes sense to create these tests once the relations between these parts/units are well-established. That doesn't have to always be after the API is completely done of course. Some internal functionalities are likely to be immutable. They can be tested quite early in the iteration timeline.
- naasking 4y ago
  We're not really talking about unit tests though, we're talking test-first. They don't have to be unit tests, which is why I described writing sample client code because that's what you need to do to anyway to design your API.
  - aatd86 4y ago
    Hum... Usually TDD is associated with unit tests and the article even mentions "unit tests" in its title... What you describe however seems closer to integration/system testing which is one approach I and other people in this thread also tend to favor. But I've been writing UI code predominantly so I am biased here as unit testing has lower value.