3 ms·

I didn't quite understand why it was a problem for start with the integration test. okay, some things need to be mocked while writing the integration test, but

by pictur 5y ago

I didn't quite understand why it was a problem for start with the integration test. okay, some things need to be mocked while writing the integration test, but I think the plus is more than the minus.

Aeolun 5y ago
It’s good to start with. Integration tests are great for finding out that ‘something’ is broken. Unit tests are better at finding what exactly is broken.
- pictur 5y ago
  Thank you for your comment. you're right, it gets harder to find the source of the error, which makes it harder to make changes. I will pay attention to this.
qayxc 5y ago
Integration tests are top-down and focus on checking that the system under test behaves as expected. They usually require elaborate setup and configuration and can - depending on the system - take considerable effort to start and run. The idea behind TDD focuses on a bottom-up approach instead - if all the parts behave as expected, it is reasonable to assume that the entire system will. TDD was also intended as a tool to help identify problems with design early (e.g. too many dependencies, tight coupling, too many responsibilities, reduce/eliminate side effects, etc.), allowing for rapid feedback (tests should execute quickly and require little to no setup). Both approaches have different goals in mind and serve a different purpose. Ideally you always have both - run unit tests after each code change (i.e. often), run integration tests after each added or changed behaviour (e.g. daily or as part of an acceptance test process). Starting with integration tests much work up-front and adding unit tests after the fact can introduce considerable overhead for questionable gains.
- pictur 5y ago
  - Starting with integration tests much work up-front and adding unit tests after the fact can introduce considerable overhead for questionable gains. Thank you for your comment. I will pay attention to this.

by pictur 5y ago

Aeolun 5y ago

It’s good to start with. Integration tests are great for finding out that ‘something’ is broken. Unit tests are better at finding what exactly is broken.

pictur 5y ago
Thank you for your comment. you're right, it gets harder to find the source of the error, which makes it harder to make changes. I will pay attention to this.

qayxc 5y ago

Integration tests are top-down and focus on checking that the system under test behaves as expected. They usually require elaborate setup and configuration and can - depending on the system - take considerable effort to start and run. The idea behind TDD focuses on a bottom-up approach instead - if all the parts behave as expected, it is reasonable to assume that the entire system will. TDD was also intended as a tool to help identify problems with design early (e.g. too many dependencies, tight coupling, too many responsibilities, reduce/eliminate side effects, etc.), allowing for rapid feedback (tests should execute quickly and require little to no setup). Both approaches have different goals in mind and serve a different purpose. Ideally you always have both - run unit tests after each code change (i.e. often), run integration tests after each added or changed behaviour (e.g. daily or as part of an acceptance test process). Starting with integration tests much work up-front and adding unit tests after the fact can introduce considerable overhead for questionable gains.

pictur 5y ago
- Starting with integration tests much work up-front and adding unit tests after the fact can introduce considerable overhead for questionable gains. Thank you for your comment. I will pay attention to this.