BDD is a subclass of TDD, and is more similar to ATDD (Acceptance Test Driven Development), where…
Eric Elliott

The BDD cycle is two parts. Start with a BDD-style test. Move down to lower-level tests. The lower-level tests make the BDD test pass. That’s the cycle and it works very well.

Lower-level tests have a different focus than the higher level BDD tests. They test more of the implementation details where yes, you could start the BDD tests outside-in say starting with a React component is where you’d start your BDD-style tests, then you’d move down to lower-level backend TDD tests then back around to see your BDD test pass.

Testing happy paths via integration tests is different then unit testing React components. Sure you may have a casper test (which is an -integration test, not unit test-) that tests a happy path for example that also might look for the same thing your react component test is testing but that’s fine, because both tests are serving different scope of testing and different kinds of testing. Unit vs. integration are completely different.

it('renders company name', () => {
const job = {id: 0, company: { name: ""}},
name = shallow(<Item job={job}/>).find('.ft-company-name').at(1).text();


That’s a react component test. Sure maybe you have a casper test that checks for a happy path and just happens to need a similar test that looks to see if company name was rendered. There’s nothing wrong with that. Unit tests serve a different purpose, they’re not testing happy paths.

I’ve found a very nice flow with my React components and my BDD flow.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.