나는 단위 테스트를 처음 접했고 TDD 접근법을 사용하기를 원하지만 현재는 모든 기존 클래스의 단위 테스트를 작성하여 모든 경우의 기능을 검증한다고합니다.테스트중인 클래스에서 메서드가 호출되었는지 테스트하려면 어떻게해야합니까?
많은 문제없이 NUnit 및 Rhino mock을 사용하여 대다수의 코드를 테스트 할 수있었습니다. 그러나, 나는 동일한 클래스 내에서 다른 많은 메소드를 호출하는 유닛 테스트 함수에 대해 궁금해하고 있습니다.
classUnderTest.AssertWasCalled(cut => cut.SomeMethod(someArgs))
과 같이 할 수 없습니다. 테스트 대상 클래스가 위조품이 아니기 때문입니다. 또한 테스트 할 메소드가 테스트중인 클래스의 다른 메소드를 호출하면 같은 클래스의 메소드를 호출하므로 "최상위 레벨"메소드를 테스트하기 위해 많은 양의 값을 가짜로 만들어야합니다. 또한이 "하위 메서드"를 모두 단위 테스트하기 때문에 "SomeMethod"는 단위 테스트를 통과하고 하위 메서드의 세부 정보를 걱정할 필요가 없다면 예상대로 작동한다고 가정 할 수 있어야합니다.
이public DataSet ExportExcelDocToDataSet(bool headerRowProvided)
{
DataSet ds = new DataSet();
for (int i = 0; i < currentWorkbook.NumberOfSheets; i++)
{
ISheet tmpSheet = currentWorkbook.GetSheetAt(i);
if (tmpSheet.PhysicalNumberOfRows == 0) { continue; }
DataTable dt = GetDataTableFromExcelSheet(headerRowProvided, ds, tmpSheet);
if (dt.Rows.Count > 0)
{
AddNonEmptyTableToDataSet(ds, dt);
}
}
return ds;
}
public DataTable GetDataTableFromExcelSheet(bool headerRowProvided, DataSet ds, ISheet tmpSheet)
{
DataTable dt = new DataTable();
for (int sheetRowIndex = 0; sheetRowIndex <= tmpSheet.LastRowNum; sheetRowIndex++)
{
DataRow dataRow = GetDataRowFromExcelRow(dt, tmpSheet, headerRowProvided, sheetRowIndex);
if (dataRow != null && dataRow.ItemArray.Count<object>(obj => obj != DBNull.Value) > 0)
{
dt.Rows.Add(dataRow);
}
}
return dt;
}
...
당신은 그것을 볼 수 있습니다 여기에
내가 내 지점을 설명 돕는와 함께 일한지 몇 가지 예제 코드입니다 (나는 NPOI를 사용하여 Excel 파일의 가져 오기/내보내기를 관리하는 클래스를 작성했습니다) ExportExcelDocToDataSet (이 경우 내 "최고 수준"방법은)이 같은 클래스 내에서 정의 된 다른 방법 중 몇 가지를 호출 GetDataRowFromExcelRow를 호출 GetDataTableFromExcelSheet를 호출합니다.그래서이 코드를 리팩토링하여 하위 메서드에서 호출 한 값을 스텁하지 않고도 단위 테스트를 쉽게 수행 할 수있는 전략은 무엇입니까? 테스트중인 클래스에서 메서드 호출을 위조하는 방법이 있습니까?
도움이나 조언을 미리 보내 주셔서 감사합니다.
AssertWasCalled 확장을 사용하여 단위 테스트를 할 수 있도록 별도의 클래스로 언급 한 메서드를 추출 할 생각을 했었습니다. 그러나 이것이 매우 얕은 클래스 톤으로 이어지는 것을 볼 수 있었기 때문에 이것이 훌륭한 아이디어인지 확실하지 않았습니다. 최대 하나 또는 두 가지 방법. 나는 당신이 추천 한 책과 SRP에 대해 더 자세히 알아볼 것입니다. 이 모든 것에 대한 가장 좋은 점은 프로젝트의 유일한 사람이고 모든 코드가 나에 의해 작성되었으므로 작업을 수행하기 위해 필요한 모든 작업을 수행 할 수 있습니다. –
@Gage Trader : 메소드의 수를 기준으로 클래스를 측정하지 마십시오. 예를 들어 커맨드 패턴은 하나의 메서드 만 노출하고 여전히 widley 사용 기법입니다. 단위 테스트와 좋은 OO 설계 원칙을 적용하기 전에 더 많은 수의 클래스에 만족하지 못했습니다. 나는 더 많은 수의 수업이 더 많은 일을 의미하지 않는다는 것을 깨닫기 위해 어느 정도 시간이 걸렸다. 예, 디자인 및 테스트에 더 많은 시간이 필요하지만 더 높은 품질과 낮은 버그 수를 통해이를 보완 할 수 있습니다. –