728x90 반응형 개발 55 [Effective Kotlin] Item 10: Write unit tests Intro 코드를 더 안전하게 만드는 궁극적인 방법: 다양한 종류의 테스트를 사용하는 것 일반적인 테스트: 사용자 관점에서 애플리케이션이 올바르게 작동하는지 확인 애플리케이션 외부에서 올바르게 작동하는 것이 목표 충분한 수의 tester를 처리 개발자에게 유용하지만 불충분함 => 단위테스트가 필요한 이유 시스템의 구체적인 element들의 올바른 작동을 보장하지 못함 개발 중에 더 빠른 피드백을 제공하지 못함 단위 테스트 (Unit test) 구현된 elements의 작동방식에 대해서 빠른 피드백을 제공하기 때문에 개발중에 유용함 테스트는 누적되므로 regression에 있어서도 쉽게 확인 가능 수동으로 테스트하기 어려운 사례도 확인가능*TDD(Test Driven Development)방식에서는 단위테.. 2021. 8. 12. [Test - Spock + Kotlin] Mocking 실패 문제 Spring Boot + Spock Framework + Kotlin 조합으로 UnitTest 코드를 작성하다 문제를 마주하게 되었다. 이 문제는 재직중인 회사에서 tc를 작성하던 중 발생한 문제로, 소스코드를 그대로 담을 수 없어 최대한 비슷한 코드를 따로 작성해보았다. 결론부터 말하자면, 나와같은 환경, 상황이 발생한다면 Spock Framework를 사용하여 test를 진행하기 어려울 것 같다 ㅠㅠ 일단 문제가 발생한 코드는 아래와 같다. class HelloTest extends Specification { HelloDao helloDaoMock HelloService helloService def setup() { helloDaoMock = Mock(HelloDao) //문제 발생 helloSe.. 2021. 7. 14. [오브젝트] 14장. 일관성 있는 협력 일관성 없는 코드의 문제점 1. 개념적으로 연관되어있는 코드에 대해 서로 다른 구현 방식을 채택할수록 설계의 일관성이 무너지게 됨 2. 코드를 이해하기 어려움: 한가지를 이해했다고 다른 한가지를 이해하는 것이 아님 결론은 유사한 기능을 서로 다른 방식으로 구현 해서는 안 된다는 것이다. 일관성 없는 설계와 마주한 개발자는 여러 가지 해결 방법 중에서 현재의 요구사항을 해결하기에 가장 적절한 방법을 찾아야 하는 부담을 안게 된다. 유사한 기능은 유사한 방식으로 구현해야 한다. 객체 지향에서 기능을 구현하는 유일한 방법은 객체 사이의 협력을 만드는 것 뿐이므로 유지보수 가능한 시스템을 구축하는 첫걸음은 협력을 일관성 있게 만드는 것이다. 설계에 일관성 부여하기 일관성 있는 설계를 만드는 데 가장 훌륭한 조언.. 2021. 7. 14. [오브젝트] 10장. 상속과 코드 재사용 상속과 중복 코드 DRY 원칙 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야 한다. DRY(Don't Repeat Yourself)는 '반복하지 마라'라는 뜻 중복 코드는 변경을 방해 코드를 수정하는 데 필요한 노력을 몇 배로 증가 시킴 중복 여부를 판단하는 기준은 변경 → 요구사항이 변경 됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복 중복과 변경 중복코드는 새로운 중복코드를 부르고, 버그 발생가능성도 높아짐 (아주아주 문제가 많다 이마리야) 민첩하게 변경하기 위해서는 중복코드를 추가하는 대신 제거해야한다. 중복을 제거하는 방법 중 하나: 클래스를 하나로 합쳐 타입코드를 추가해 로직 분기 → 단점: 낮은 응집도와 높은 결합도를 갖게됨 상속을 이용해서.. 2021. 6. 4. [오브젝트] 9장 유연한 설계 01. 개방-폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 여기서 키워드는 '확장'과 '수정'이다. 이 둘은 순서대로 애플리케이션의 '동작'과 '코드'의 관점을 반영 확장에 대해 열려 있다: 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다. 수정에 대해 닫혀 있다. 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다. 컴파일 의존성을 고정시키고 런타임 의존성을 변경하라 의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란, 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조를 의미 컴파일 의존성: 코드.. 2021. 6. 3. multi-part file 413, 501 error 해결하기 Overview 클라이언트의 브라우저에서 파일을 업로드할 때, 작은 파일 (1MB 이하)의 파일은 잘 업로드 되지만 1MB를 넘는 파일은 업로드가 실패하는 문제가 발생했습니다. 발생한 문제와 해결 방법에 대해서 간략하게 정리해보겠습니다. 413 error 가장 먼저 마주한 문제는 413 Request Entity Too Large error였습니다. 413 error의 경우 클라이언트의 브라우저에서 파일 업로드를 수행할 경우 파일 용량이 제한되어 발생할 수 있는 error입니다. 이때 nginx를 사용중이라면, nginx의 파일 업로드 크기를 정해 문제를 해결할 수 있습니다. 만약 파일 업로드 크기를 따로 설정하지 않은 경우, 파일의 크기가 1M가 넘는 경우에 에러가 발생할 수 있습니다. nginx에서 .. 2021. 3. 23. 이전 1 2 3 4 5 6 7 8 ··· 10 다음 728x90 반응형
