Incrível. Apesar de não dominar bem o inglês mas consegui abstrair cada parte dessa incrível jornada de como testar um código legado. Obrigado pela excelente contribuição!
4:55 1st piece of code 5:57 business rule 6:39 goal of working with legacy code: no test => cannot start refactoring immediately 6:48 => idea: write tests until we have 100% test coverage, then refactor 7:14 *challenge: retrofitting tests for existing code is not easy* 7:52 problem: 8:21 so the only thing we need to do: *automatic refactoring* 8:57 *if we change the public interface of the class or module, we are going to break the code* 9:21 if we *introduce state* => multi-threading problem 9:40 important tip: try best to *keep the public interface intact, but still try to isolate the dependencies* 9:49 *technique* : landscape of code 10:42 *shallow branch* - shortest path to the exit of the method 11:32 try to understand the small piece of code and write unit tests on it 12:34 build the knowledge of that code base *one test at a time* 12:40 in order to get the *deepest branch* of the code, need to *play the input data* 13:24 coding demo in practice
Thanks for tips! I would consider further refactoring: move the loggedinuser parameter to another interface like Context#requireCurrentUser() that, in turn, will throw an exception, and inject that context to the service. As a result, the service won't care of the nullable user at all. I feel the code will become simpler and more RSP'ish :)
