[💬] 유니티랑 합체하는게 너무어려워

[익명(175.223)]

유니티에 기능이 있긴 있는데
뭐가 있고 어디까지 있는진 완벽히 모르잖아
그래서 만들다보면 내가 편의성 구현한거랑 유니티에 있는거랑 반드시 겹쳐버림
그 자체로 끝나면 괜찮은데
다른기능이 해당 유니티 기능의 사용을 전제로 할때
갈아엎어야됨
.ㅅ. 어려움

- dc official App

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(175.223)]

최근엔 메세지패스 시스템이 맘에 안들어서 만들었는데 이미 uniRX가 있더라고.. - dc App

[익명(175.223)]

ㅇㅇ 그래서 더 모르겠어 메인 사이트에 문서화된것도 아니고 에셋스토어가 필수는 아니지만 있는거 그대로 만들고있음 바보가 된 느낌.. - dc App

[익명(175.223)]

검색능력이 필요한가.. - dc App

[산적대왕(125.137)]

그래서 난 거의 대부분의 연산이 유니티 없이도 돌아가게 만들어. 유니티를 일종의 View 로 쓰는 식. 충돌이나 그런 건 어쩔 수 없지만, 유니티에서 분리될수록 테스트가 쉬워진다. 코드 하나 고칠때마다 유니티 켜서 돌려볼 필요가 줄어든다는 거. 유니티 함수들이 뭣같은게 유니티 외부에서 호출하면 보안익셉션 띄워버림 ㅅㅂ

[익명(175.223)]

아예 그런 방법도 있네요. 전 왠지 프레임워크를 쓰면 그 동네에 있는것들을 꼭 이용해야 될거같은 주입식교육의 폐해임 ㅜㅜ - dc App

[익명(175.223)]

근데 그럼 모델 유닛테스트도 유니티에서 지원하는 테스트말고 독자적으로 하시는건가요? 뷰에는 파라미터 넣어서 테스트하고 - dc App

[익명(175.223)]

좋은 테스트 방법이 있다면 알려주세요 다 만들면 테스트를 하고싶은데 그짝은 무지식이라 ㅎㅎ; - dc App

[산적대왕(125.137)]

좋은 테스트법은 나도 배우고 싶은 심정이고... 일단 쓰는 방법은 프로젝트를 네이티브 레이어랑 유니티 레이어로 나눠서 네이티브 클래스들은 Nunit으로 유닛 테스트 개념으로 돌리고 유니티부분은 유니티 테스트써서 통합 테스트 개념으로 돌리는 중. 그리고 젠젝트를 이용해서 테스트 상황에 따라 조립해서 쓰고있어. 근데 이런 방법이 장점은 있지만 좀 시간낭비도 있다는 느낌이니 나처럼 테스트 중독되기 전에 이래저래 더 찾아보길...

[산적대왕(125.137)]

의존성... 의존성이 문제다. 사람... 사람이 문제다.

[익명(175.223)]

ㄱㅅㄱㅅ! - dc App

[ㅇㄷㄴ(210.126)]

만드는게 쉬우면 그냥 만드는게 나중을 위해 속편함.