What would the best approach be? Write unit tests for them, or question why they're there?
Excluir código é bom.
Quando você não pode excluir o código, certamente pode marcá-lo como @Deprecated , documentando qual importante release que você está direcionando para remover o método. Então você pode excluí-lo "mais tarde". Nesse meio tempo, ficará claro que nenhum código novo deve ser adicionado que dependa dele.
Eu não recomendaria investir em métodos obsoletos - portanto, nenhuma nova unidade testa apenas para atingir as metas de cobertura.
A diferença entre os dois é principalmente se os métodos são ou não parte da interface publicada . A exclusão arbitrária de partes da interface publicada pode ser uma surpresa desagradável para os consumidores que dependiam da interface.
Eu não posso falar com EclEmma, mas pelas minhas experiências uma das coisas que você precisa ter cuidado é a reflexão. Se, por exemplo, você usar arquivos de configuração de texto para escolher quais classes / métodos acessar, a distinção usada / não usada pode não ser óbvia (eu já queimei isso com um tempo acoplado).
Se o seu projeto é uma folha no gráfico de dependência, o caso de depreciação é enfraquecido. Se o seu projeto é uma biblioteca, o caso da reprovação é mais strong.
Se sua empresa usa um reporte mono , a exclusão é um risco menor do que no caso de vários repo.
Como observado por l0b0 , se os métodos já estiverem disponíveis no controle de origem, recuperá-los após a exclusão é um procedimento direto exercício. Se você estava realmente preocupado com a necessidade de fazer isso, pense em como organizar seus commits para poder recuperar as alterações excluídas, se precisar delas.
Se a incerteza for alta o suficiente, você pode considerar comentar o código , em vez de excluí-lo. É um trabalho extra no caminho feliz (em que o código excluído nunca é restaurado), mas facilita a restauração. Meu palpite é que você deve preferir uma exclusão direta até que você tenha sido gravada por um par de vezes, o que lhe dará algumas idéias sobre como avaliar a "incerteza" neste contexto.
question why they're there?
O tempo investido na captura do conhecimento não é necessariamente desperdiçado. Eu sou conhecido por realizar uma remoção em duas etapas - primeiro, adicionando e confirmando um comentário explicando o que aprendemos sobre o código e depois excluindo o código (e o comentário).
Você também pode usar algo análogo a registros de decisões arquiteturais como forma de capturar o lore com o código fonte.