자이닉스 개발부

그럼 이제 실제로 Blend 3에서 Behavior를 어떻게 사용할 수 있는지 보도록 하겠습니다.
이미 만들어놓은 SketchFlow Project를 열어 트리 구조를 보면, 아래 사진과 같이 보입니다.
녹색 박스 안의 ImageSlideViewerContainer는 Grid이며 안에는 4장의 이미지가 있습니다.
첫번째 이미지의 RotationY는 0
두번째 이미지의 RotationY는 -90
세번째 이미지의 RotationY는 90
네번째 이미지의 RotationY는 180
이런 식으로 설정되어 있으며 4장의 이미지들의 CenterRotationZ를 Image의 Width의 절반으로 값을 주었습니다.

원하는 움직임은 btnLeft (왼쪽 방향 화살표)를 눌렀을 때, 이 이미지들이 90도씩 RotationY가 변하여 회전하길 바라는 것입니다.

Assets의 Behaviors로 들어가면 ChangeRotation이 있습니다. 이것을 마우스로 Drag하여 btnLeft에 Drop을 하면 됩니다.

Drop을 하면 오른쪽 Properties창에 Behavior를 설정할 수 있도록 아래 사진과 같은 내용들이 나타납니다.

사용자가 btnLeft를 마우스 외쪽 버튼으로 클릭하게 되면 ImageSlideViewerContainer가 ChangeRotation을 일으킵니다.

그 하위에 Rotation, Rotation Properties, Target은 Behavior 소스 코드 상에서 직접 Catalog를 만든 것입니다.

ImageSlideViewerContainer의 Children인 4장의 이미지를 회전시키고 싶은 것이기 때문에, Target Catalog에서 isChildren을 체크합니다. 그 후에, RotationY를 체크하고 DeltaY에 90을 입력하게 되면 모든 설정을 마친 것입니다. ^_^

SketchFlow Project를 만들어봅니다.
1. Expression Blend3 를 실행
2. New Project
3. Silverlight 3 SketchFlow Application 프로젝트 생성

SketchFlow 화면 구성
빨강 : 프로젝트 파일부터 Resource 파일들의 목록 및 Assets, States를 설정할 수 있는 부분
주황 : 스크린을 구성하고 있는 UIElement들의 Tree 구조
노랑 : 미리보기 화면
초록 : 각 Screen들의 상관관계와 흐름을 한 눈에 볼 수 있는 Map
파랑 : Element들의 속성 및 Resource와 Data들의 정보를 조작

SketchFlow Map을 제외하곤 Expression Blend와 거의 동일한 화면 구성이다.

Screen? 실제로 보여지는 화면
1. UserControl Class를 생성하듯이 SketchFlow에서만 쓰이는 Screen들을 마우스로 끌어내는 것만으로 쉽게 생성할 수 있다.
2. Screen의 이름을 바꿀 수 있다.
3. 목적에 따라 한 눈에 알아 볼 수 있도록 색을 바꿀 수 있다.
4. 화살표 방향으로 각 Screen들끼리의 소통과 흐름을 파악할 수 있다.

Component Screen? 반복적인 요소
1. 어떠한 부분이 필요에 의해 여러 Screen에 중복적으로 쓰일 때 Component Screen을 이용한다.
2. Component Screen을 연결한 Screen에는 Component Screen이 삽입된다.

그리고 나는,
...ImageSlidePlayer를 SketchFlow Project로 만들며 삽질을 하였다...

SketchFlow Project를 만들며 알게 된 점
1. 평범하고 단편적인 애니메이션은 Behavior를 이용하면 된다.
2. 평범하지 않은 애니메이션은 스스로 Behavior를 만들거나 코딩이 필요하다.
3. Insert시킨 Screen의 속성을 건드릴 수가 없다. (Element Binding을 시키려 할 때나 애니메이션을 적용시킬 때 이 문제 때문에 한참을 헤매다 포기했다.)
4. 버튼이나 기타 Element를 활용한 Screen이동이 활발한 프로그램일 수록 SketchFlow 효과도 좋다. (본인이 적용한 프로그램은 한 화면에서 움직이기 때문에, Screen이동이 거의 없어 밋밋하고 Component Screen을 쓰기도 힘들었다.)
5. Resources에 DataTemplate을 만들어서 ListBox에 DataBinding을 했을 때, ListBox의 Items.Count는 0이다. (몰랐다.) SelectedItem을 뽑아보려는 짓은 부질없었으며 Data접근도 복잡하다.

아직도 모르겠는 것 - State 사용법, SketchFlow Animation

아직 안 해 본 것 - 포토샵이나 일러스트레이터 프로젝트 파일이 없어 Import 시켜보지 않았다.

MS Word로 Export 시켜낸 결과물 (보고서)

ImageSlidePlayer.doc

 
  Model/DataModel은 Parser와 같은 역할을 하여 metadata들을 갖고 있고 metadata는 필요(사용자의 Request)에 따라 service될 것이다. 사용자의 Request가 View를 통해 접수되면, ViewModel이 Request에 적합한 동작을 수행하고, 그 동작에 필요한 데이터 정보는 Model/DataModel로부터 얻는다.

  자, 그렇다면 Command Pattern은 왜 필요할까? Command Pattern은 ViewModel이 View의 Request를 받아 동작을 수행하는 과정에서 적용시킨다. Command Pattern은 각종 Request들에 반응하는 Action들을 개별로 캡슐화시킬 수 있기 때문에, 재활용성이 용이하며 View와 ViewModel을 분리시키는데 한 몫을 한다.

  자세한 설명은 밑에 Nikhilk과, 길버트라는 분들이 자세히 설명과 적용 사례까지 적어 놓았으니 참조하면 좋겠다.

참조 링크

http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx

http://error1001.com/36

참고 자료 _ Unit Testing with Silverlight 2
원문 _ Silverlight2 Unit Test

이제 add 함수를 테스트 하기 위해서 실제로 UnitTest를 수행할 프로젝트를 생성한다.

UnitTestApp 솔루션에 Test라는 새 프로젝트를 추가한다. (템플릿은 Silverlight Test Project를 선택한다)

생성된 Test.cs 파일을 살펴보면 Test Class 앞에는 [TestClass]가 선언 되어 있고 테스트 함수 앞에는 [TestMethod]가 선언 되어있는 것을 알 수 있다.

Test 프로젝트를 실행하면 [TestClass]로 선언된 Class 안에 포함된 [TestMethod]를 수행하여 실제 UnitTest를 수행하게 된다.

아래와 같은 Test 함수를 추가하여 add 함수를 테스트 한다.

[TestMethod]

public void AddTest()

{

MyTestClass myTestClass = new MyTestClass();

Assert.AreEqual(3, myTestClass.add(1, 2));

}

이때 MyTestClass는 Test 프로젝트에 포함되어 있지 않기 때문에 Test 프로젝트 참조에 UnitTestApp를 추가하고 Test.cs에 using UnitTestApp; 를 추가해야 정상적으로 빌드 된다.

빌드가 완료되어 Test 프로젝트를 실행하면 다음과 같은 화면을 통해 테스트가 정상적으로 수행 되었음을 알 수 있다.

테스트 오류 상황을 확인하기 위해 Assert.AreEqual(3, myTestClass.add(1, 2)); 부분을 Assert.AreEqual(5, myTestClass.add(1, 2)); 로 수정해본다. 수정 후 실행 결과는 다음과 같다.

AddTest 함수에서 오류가 발생한 것을 알 수 있으며 기대값과 실제 값을 확인할 수 있다. 이때 AddTest를 클릭하면 더 자세한 정보를 확인할 수 있다.

다음은 컬렉션의 값이 추가 되었을때 정상적으로 이벤트가 발생하는지 테스트하는 항목을 만들어본다.

MyTestClass에 다음과 같은 멤버 변수와 함수를 추가한다.

internal ObservableCollection<int> collection = new ObservableCollection<int>();

public void addCollection(int value)

{

collection.Add(value);

}

그리고 addCollection 함수를 테스트 하기 위해 Test 프로젝트의 Test 클래스에 다음과 같은 Test 함수를 추가한다.

테스트 내용은 addCollection을 한번 호출하였을 때 Collection의 값이 변동이 되었다는 이벤트를 받아 이벤트가 정상적으로 발생 되었는지, Collection에 포함된 자료의 갯수가 한개인지 확인하게 된다.

[TestMethod]

public void CollectionTest()

{

MyTestClass myTestClass = new MyTestClass();

bool changedValue = false;

myTestClass.collection.CollectionChanged += delegate(object sender, NotifyCollectionChangedEventArgs e)

{

changedValue = true;

Assert.AreEqual(NotifyCollectionChangedAction.Add, e.Action);

Assert.AreEqual(1, e.NewItems.Count);

};

myTestClass.addCollection(5);

Assert.IsTrue(changedValue);

}

이 코드를 추가하고 다시 빌드를 실행하면 internal로 선언된 collection 때문에 오류가 발생한다. 이는 Test 프로젝트와 UnitTestApp가 서로 다른 namespace이기 때문인데, 테스트를 위해서 collection을 public으로 바꾸는 방법도 있지만, UnitTestApp에 있는 AssemblyInfo.cs 파일을 수정하여 UnitTestApp에 있는 internal 을 Test 어셈블리에서도 access 가능하게 수정하도록 한다.

internal로 선언된 변수를 다른 어셈블리에 공개하려면 AssemblyInfo.cs 파일에 다음을 추가하면 된다. (AssemblyInfo.cs 파일은 Properties 폴더에 있음)

[assembly: InternalsVisibleTo("Test")]

빌드가 정상적으로 되고 Test 프로젝트를 실행하면 정상적으로 테스트를 성공하는 것을 확인할 수 있다.

3. UI Unit Test

---

UI를 테스트 하기 위해서는 테스트 대상이 될 어플리케이션을 임시로 생성하고 사용자 입력을 자동으로 만들어서 테스트를 수행하여야 한다.

UnitTestApp의 Page.xaml에 다음과 같은 코드를 생성하자.

<StackPanel>

<TextBox x:Name="InputText" />

<Button Content="Click" Click="Button_Click" />

<TextBlock x:Name="OutputText" />

</StackPanel>

Button을 클릭하면 InputText에 있는 내용을 OutputText로 뿌려주도록 한다.

private void Button_Click(object sender, RoutedEventArgs e)

{

OutputText.Text = InputText.Text;

}

구현한 위의 동작을 테스트 하기 위해서 Test 프로젝트에 새로운 테스트 클래스인 UITest를 생성하자. (Silverlight Test Class 템플릿을 사용)

UITest를 이용해서 어플리케이션의 UI를 테스트 하기 위해서는 [TestMethod]가 수행될 때마다 어플리케이션을 임시로 생성해야 하는데, 이것은 [TestInitialize]를 이용하여 할 수 있다. 함수 앞에 [TestInitialize]를 선언하면 그 함수는 [TestMethod]가 수행될때마다 [TestMethod]이전에 실행되어서 원하는 값들을 초기화 시킬 수 있다.

(초기화 뿐만 아니라 [TestCleanup]을 이용하여 [TestMethod] 수행 종료 이후에 테스트 후의 환경을 정리할 수도 있다.)

[TestInitialize] -> [TestMethod] -> [TestCleanup] 순서로 수행 됨

실제로 테스트를 수행하기 위해서는 [TestInitialize] 함수에서 UnitTestApp의 페이지를 생성하고, 그 페이지를 SilverlightTest 클래스안에 있는 TestPanel의 Children에 추가시켜야 한다. 이것을 위해서 실제 테스트 클래스를 SilverlightTest를 상속받는 클래스로 생성한다.

using UnitTestApp;
using Microsoft.Silverlight.Testing;

[TestClass]

public class UITest : SilverlightTest

{

private Page testPage;

[TestInitialize]

public void PreparePage()

{

testPage = new Page();

TestPanel.Children.Add(testPage);

}

}

준비가 끝났으면 실제 테스트를 수행하는 함수를 작성한다.

[TestMethod]

public void TextBoxTest()

{

testPage.InputText.Text = "TextBoxTest";

testPage.Button_Click(this, null);

Assert.AreEqual("TextBoxTest", testPage.OutputText.Text);

}

빌드를 해보면 오류가 발생한다. Page.xaml.cs 파일을 보면 Button_Click이 private으로 선언 되어 있는데 이것을 internal로 수정한다.

(internal로 수정해서 빌드가 가능한 이유는 AssemblyInfo.cs 파일에 Test 어셈블리를 internal 범위에 포함시켰기 때문이다. internal 범위에 포함시키지 않았다면 testPage의 InputText나 OutputText도 사용할 수 없다.)

빌드가 정상적으로 진행되어 실행해보면, 작성한 Page.xaml의 내용이 화면에 깜박거리면서 테스트가 진행되는 것을 볼 수 있으며 다음과 같은 결과를 확인할 수 있다. (실제로는 UI 화면이 깜박거리면서 사라진다.)

이 포스팅에 사용된 샘플 소스

 UnitTestApp.zip