News for hackers. Stuff that matters.
Re:The Second Edition of “Refactoring” by danmaz74 on Saturday December 01, 2018 @06:09PM (#18579582)
I can't comment on other articles, but I would be careful with some suggestions about mocking everything in automated tests. I've seen a couple of totally botched projects because of that approach.
Re:The Second Edition of “Refactoring” by jammygit on Sunday December 02, 2018 @01:26AM (#18581108)
How did the mocks do the damage? Lack of integration tests, wasted time, or something else?
Re:The Second Edition of “Refactoring” by danmaz74 on Sunday December 02, 2018 @06:47AM (#18581949)
Yes, the biggest problem was the lack of integration* tests: you can get a false confidence that everything is working, but you only know that the individual cogs are built to spec, not that the machine is working.

Second problem was that refactoring became much harder, because the tests were deeply tied to the implementation (are methods X, Y and Z called with such and such arguments?).

* using the definition of "integration" as "integrating components of the project", not "integrating with external services" (which is the definition I personally prefer).

Re:The Second Edition of “Refactoring” by billsix on Sunday December 02, 2018 @01:48AM (#18581170)
It results in tautological tests.
Re:The Second Edition of “Refactoring” by softawre on Monday December 03, 2018 @03:18PM (#18592504)
Not really. I mean, you're still testing that the compiler works and that the memory works. ;)