utterances-bot commented 9 months ago

Unity MVP를 TDD로 구현하기 - 공부 블로그 Blue log

https://fkdl0048.github.io/unity/unity_in_MVPForTDD/

steven060594 commented 9 months ago

안녕하세요, 최종 구성에서 SettingsUIView가 SettingsUIPresenter를 알고, 반대로 SettingsUIPresenter도 SettingsUIView를 알고 있는데 이런 참조관계도 괜찮은 건가 의문이 들어서 질문 드립니다!

fkdl0048 commented 9 months ago

안녕하세요! 유니티 특성상 Mono를 상속받은 View가 씬에 존재하고 해당 이벤트 함수로 Presenter를 생성하는 구조인데, MVP구조 특성 상 View와 Presenter가 1:1의 관계를 가져서 저런 구조로 작성했습니다.

좀 너 느슨한 결합은 MVVM을 참고하셔도 좋을 것 같습니다!

View Data Presenter의 각 구조만 명확하게 하려고 작성한 코드라 아직은 많이 부족한 것 같습니다..

지금은 위 코드에서 구조가 많이 바뀌고 있습니다!

steven060594 commented 9 months ago

넵 감사합니다..!

abysslover commented 8 months ago

관련 키워드로 검색하다가 들어와 봤어요. Test는 보통 값 assign 하는 것처럼 단순한 작업에는 생성하지 않는데, 혹시 Back-end 단 데이터 처리 관련된 부분이 아니라 Unity 내에서 Front-end 단에서 TDD 를 적용했을 때 의미가 있는 품질 향상이 있으셨나요?

fkdl0048 commented 8 months ago

지금은 위 코드와 매우 다른 상태입니다! 과거 Unity Editor Mode로 Test코드를 돌려서 [Test] 애트리뷰트로 설정하고 Editor에서 테스트 코드를 실행했습니다.

말씀해주신 대로 데이터 처리 단위에서 Back-end로 밖에 못 돌리는 경우가 생겨서(NSubstitute) 지금은 테스트 코드를 PlayMode로 옮기고 코루틴을 이용한 테스트로 되어 있습니다.

실제 Gameobject를 생성하고 그 오브젝트에 View Front에 해당되는 오브젝트들(슬라이드, 버튼)등을 부착하고 실제 런타임에서 동작하게 했습니다.

결론은 좋은 테스트 커버리지가 좋은 제품을 보장하지 못하듯이 아직까지는 품질향상을 느낀적은 없습니다. 작업이 좀 더 생겨서 생각해야 할 부분들이 많이 생겨서 전체적인 초기 작업 속도는 느려졌지만.. 좀 더 멀리 봤을 땐 테스트 코드로 문서화되고 자동화가 보장된다면 그 때는 품질 향상을 체감할 수 있을 것 같습니다..

TDD관점보단 테스트 코드에 대해서 이야기 한 것 같은데 TDD의 경우엔 지금은 사용하지 않고 있습니다. 아직 제대로된 설계도 못하는데 TDD를 사용한 것 같아서 좀 더 설계적으로 경험이 오르면 다시 도전해볼 것 같습니다.

본문에도 있지만, TDD에 대해서 조금이라도 이해해보고자 해본 도전입니다.. ㅎ

fkdl0048 / Blog_Comments

unity/unity_in_MVPForTDD/ #8

Unity MVP를 TDD로 구현하기 - 공부 블로그 Blue log