| Yeah I think this is problem with characterizations of "but this branch is telling lies." It's not; running tests reveals the state of the branch. And the coder also might have some idea of far away that branch is from merging to master. Let's consider it this way: Common starting point A, current master, where everything passed already. Two people are working on their own mostly independent features on branches: B1 and B2. So who's the next master? Well it depends on which of the two finishes first. If B1 tests their branch and they are the first to merge, well there's no double work. They tested what would be the next master. Say B2 finishes next. If they run their tests now, they have a good idea if their own changes are the problem or not. If they wait to rebase and then test, they now need to consider two causes: (1) their own changes and (2) the combination of B1 and B2 changes. Sure for a small enough change and good enough set of test cases, the combination of B1 and B2 won't be hard to figure out. But then the situation already is the team knows how to build big features out of many small changes. I would say that's not the majority of the developers out there IME. Slow regarding build and running really depends... We've gone over to more test oriented coding because the automated tests help us do better than manual testing. A collection of tests built up over time tracks the gotchas/corner cases/etc. If the developer were better at catching bugs without these test cases, then we would still be doing it manually. But I would rather wait 3 hours for my automated tests than spent 3 hours double/triple checking my code. The specifics do matter; for some code bases the approach in the article may be right. But building and running some thing twice may not be the wrong thing. I think there's a failure to realize there's an engineering and process design/compromise to be made... |