Czy warto wprowadzać do projektu standardy testów jednostkowych

Cześć
Zastanawiam się jakie korzyści niesie za sobą stworzenie standardów testów (jednostkowych i integracyjnych) dla dużych projektów. No super, wszystkie testy będą miały tę samą konwencję nazw, ale co poza tym? Możecie się podzielić jakimiś swoimi przykładami z życia kiedy takie coś miało realny sens zastosowania?
Dzięki za odpowiedzi ;)

Jeżeli nie widzisz więcej korzyści poza Cyt: No super, wszystkie testy będą miały tę samą konwencję nazw, ale co poza tym to słabo,
Testy dają chociażby bezpieczeństwo robienia zmian i nie rozwalenia wszystkie dookoła

• Dobra konwencja nazewnicza w testach zapewnia nie tylko jednolitość tego nazewnictwa. Wymusza także dobry design testów. Ja np. stosuję ten wzorzec: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html - dzięki takim nazwom autor testu musi określić (a więc przemyśleć), co w zasadzie ten test testuje, w jakich warunkach. Kiedy widzę coś w stylu testUiSetup, to tak naprawdę nie mam pojęcia, co taki sprawdza. Często jest w nim bałagan.
• Standardy to nie tylko nazewnictwo, ale też pewne zasady. Np. to, że dany test powinien testować tylko jedną rzecz. To niekoniecznie znaczy, że musi zawierać dosłownie tylko jedną asercję, jak chcą niektórzy puryści. Ja aż takim hardkorem nie jestem, żeby np. osobny test sprawdzał, czy zwracana kolekcja nie jest nullem, a osobny, czy nie jest pusta. To przesada. Ale powinien sprawdzać jeden koncept. Nierzadko widywałem na produkcji testy, które sprawdzają mnóstwo rzeczy naraz. A nawet modyfikują sobie pomiędzy asercjami dane testowe i jadą z kolejnymi asercjami : ) I to było pisane przez ludzi z wieloletnim doświadczeniem. Dobra konwencja zakazuje czegoś takiego.
• Testy latwo napisać, trudniej je utrzymać. Typową bolączką jest kwestia aranżacji, czyli przygotowywania danych do testów. Dotyczy to zarówno mocków, stubów, jak i generowania rozmaitych sztucznych zestawów danych na potrzeby testu. Gdy jest to za każdym razem improwizowane, pojawiają się problemy z cyklu "dodaliśmy nowy parametr do konstruktora, i nagle pół tysiąca testów się nam nie buduje". Dobrze jest stworzyć w kodzie testowym metody pomocnicze, które w tym pośredniczą i pomagają w uproszczony sposób inicjalizować obiekty. Wtedy testy nie są tak wrażliwe na refaktoryzację, bo w razie czego niezbędne zmiany będą skoncentrowane w tej warstwie pomocniczej, a nie rozsiane po wszystkich testach. Żeby to mogło sprawnie i spójnie funkcjonować, trzeba się zgodzić na pewne standardy w tym względzie.
• W temacie testów polecam teksty tego Osherove'a (vide link w pierwszym punkcie), jak również jego bardzo ciekawe klipy, w których np. przegląda i recenzuje kod testowy z prawdziwych, poważnych projektów open-source'owych. Skupia się on na C#, ale myślę że jego wskazówki są cenne niezależnie od stosowanego języka... a juz tym bardziej Javowiec nie powinien mieć większych kłopotów z czytaniem kodu w C#.

Oczywiście nie kwestionuję pisania testów, wręcz przeciwnie ;)
@up dzięki za bardzo rzeczową odpowiedź!

konwencje ktore stosuje:

• uzywam stylu nazewnictwa WTakiejATakiejSytuacji_SpodziewamSieTegoITamtego, np OnPriceLimitBreached_CommandRejected
• sa to w znacznej wiekszosci testy integracyjne, jednostkowo testuje jedynie niestandardowe/nietrywialne algorytmy
• w razie wykrytego buga dodaje test udowadniajacy ze zostal on naprawiony (jedyny przypadek gdy pisze testy najpierw)
• testy musza przechodzic niezaleznie od srodowiska (build server, stacja robocza dowolnej osoby z dowolnej strefy czasowej etc)

mysle ze nic nie pominelam z istotnych rzeczy