다음과 같은 것이 있습니다.
public class ModelEntity : Entity
{
public override int Id { get; set; }
public string FileName { get; set; }
}
public class DataTransferObject
{
public int Id { get; set; }
public string FileName { get; set; }
}
그리고 다음과 같이하고 싶습니다.
var model = _fixture.Create<ModelEntity>();
var dto = _fixture.Create<DataTransferObject>().FillWith(model);
지금은 다음을 수행하고 있지만 올바른 방법인지 확실하지 않습니다.
var model = _fixture.Create<ModelEntity>();
var dto = model.AsSource().OfLikeness<DataTransferObject>().CreateProxy();
AutoFixture에는 이와 같은 기능이 없지만 여기에서 배울 수있는 더 좋은 것이 있다고 생각합니다.
AutoFixture는 원래 TDD (Test-Driven Development)를위한 도구로 구축되었으며 TDD는 모두 피드백 에 관한 것 입니다. GOOS 의 정신에 따라 테스트를 들어야합니다. 테스트를 작성하기 어려운 경우 API 디자인을 고려해야합니다. AutoFixture는 이러한 종류의 피드백을 증폭시키는 경향이 있으며 여기에서도 그럴 수 있습니다.
인스턴스의 DataTransferObject
값 으로에 채울 수 있어야하는 것 같습니다 ModelEntity
. 이것은 일종의 매핑 이 API에 귀중한 추가가 될 수 있음을 시사 할 수 있습니까?
이러한 유형이 이미 결합 된 방식에 따라 클래스에 프로젝션 메소드를 추가하는 것을 고려할 수 있습니다 ModelEntity
.
public class ModelEntity : Entity
{
public override int Id { get; set; }
public string FileName { get; set; }
public DataTransferObject ToDataTransferObject()
{
return new DataTransferObject
{
Id = this.Id,
FileName = this.FileName
};
}
}
그러나이 방법의 단점은 두 유형을 서로 연결한다는 것입니다.
바람직하지 않은 경우 ModelEntity
인스턴스를 DataTransferObject
객체에 매핑 할 수있는 전용 매퍼 서비스를 대신 도입 할 수 있습니다 .
헤아릴 수없는 이유로 테스트중인 시스템에 이러한 매퍼를 도입하고 싶지 않은 경우에도 테스트 프로젝트에서 재사용 가능한 서비스로 추가 할 수 있습니다.
그러한 매퍼를 직접 작성하고 싶지 않다면 AutoMapper 와 같은 것을 그 목적으로 사용하는 것을 고려할 수 있습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다