4 ms·

> (1) no new features for a quarter or two, refactor the code, learn new methodologies etc > (2) This allows you to instantly test what you write, and mainly u

> (1) no new features for a quarter or two, refactor the code, learn new methodologies etc > (2) This allows you to instantly test what you write, and mainly use tests as specification > (3) the problem comes when you break something and a lot of tests start to fail suddenly My favorites. Don't expect to give away entire quarter, but at-least sometime would definitely be nice. All three so fundamental, and often ignored. In my experience, you get these right, it makes developer life so much easier. As someone earlier mentioned in thread, TDD is kind of like REPL driven development. I think, one immediate benefit of companies focusing on good code is that engineers can aim for much more ambitious projects, and they can be more brave with the codebase. Instead we often end up with 100 over-engineered components with no well defined/enforced contracts, and a set of monolithic tests which runs the entire stack to test the most basic case.

sidlls 5y ago
On the other hand, with TDD we often end up with code that has been butchered in the name of "testability," and which is both less efficient and more complex than necessary.
- fendy3002 5y ago
  Which IMO, a bad practice. Too much interface, abstraction, mocking do not reflect real process. I find it often break when integrated with services.
- leprechaun1066 5y ago
  This usually happens when the developers in this situation are focusing (or are being forced to focus) on the tests over focusing on the solution to the actual problem in the product. TDD is just a development methodology which is a means to an end, not the goal.
  - sidlls 5y ago
    Development methodologies exist to solve product development problems, not the product problems. In that sense, an organization that adopts TDD necessarily focuses on the tests (as part of the development process), by definition. The problem is, TDD is a poor development methodology.
  - truncate 5y ago
    Yes, I think being little extreme either ways is bad. If TDD makes it hard to test certain new thing we are implementing, maybe do it some other way. I've found functional style of programming, or just decomposing functions into smaller functions, often work better with TDD. I'm personally not as much into pure TDD, as much as writing code that can be tested quickly and easily. In the end, what I want is when I'm writing code, I should be able to quickly run that specific piece of code and verify the some basic scenarios, instead of waiting a minute to push to cluster, another couple minute starting whole process and then running actual test.
fendy3002 5y ago
This should be the way. I really like three interation approach: research, stable, enforce. First you develop fast and breaking things with alpha / beta versions. Then you make it stable with bug fixes and minor enhancements. Finally enforce the code with review, unit tests and code coverage, etc. Theoretically they already have a good game engine (long lasting product) and interested in developing it further. Without enforcement, any future changes have potential to break things. Unit tests (enforcement) reduce that risks and make any changes / refactoring closer with specification.

sidlls 5y ago

On the other hand, with TDD we often end up with code that has been butchered in the name of "testability," and which is both less efficient and more complex than necessary.

fendy3002 5y ago
Which IMO, a bad practice. Too much interface, abstraction, mocking do not reflect real process. I find it often break when integrated with services.
leprechaun1066 5y ago
This usually happens when the developers in this situation are focusing (or are being forced to focus) on the tests over focusing on the solution to the actual problem in the product. TDD is just a development methodology which is a means to an end, not the goal.
- sidlls 5y ago
  Development methodologies exist to solve product development problems, not the product problems. In that sense, an organization that adopts TDD necessarily focuses on the tests (as part of the development process), by definition. The problem is, TDD is a poor development methodology.
- truncate 5y ago
  Yes, I think being little extreme either ways is bad. If TDD makes it hard to test certain new thing we are implementing, maybe do it some other way. I've found functional style of programming, or just decomposing functions into smaller functions, often work better with TDD. I'm personally not as much into pure TDD, as much as writing code that can be tested quickly and easily. In the end, what I want is when I'm writing code, I should be able to quickly run that specific piece of code and verify the some basic scenarios, instead of waiting a minute to push to cluster, another couple minute starting whole process and then running actual test.

fendy3002 5y ago

This should be the way. I really like three interation approach: research, stable, enforce. First you develop fast and breaking things with alpha / beta versions. Then you make it stable with bug fixes and minor enhancements. Finally enforce the code with review, unit tests and code coverage, etc. Theoretically they already have a good game engine (long lasting product) and interested in developing it further. Without enforcement, any future changes have potential to break things. Unit tests (enforcement) reduce that risks and make any changes / refactoring closer with specification.