• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Make Your SW Component Testable
 

Make Your SW Component Testable

on

  • 490 views

 

Statistics

Views

Total Views
490
Views on SlideShare
490
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Make Your SW Component Testable Make Your SW Component Testable Presentation Transcript

    • Make your SWcomponents testableLi-Wei Cheng
    • Outline• Problem ?• Whats IoC ?• Method to make your software components testable
    • Problem ? (1/3) /// pseudo code for CheckAuthentication /// input: string id /// input: string password /// output: true --> if pass the checking /// false --> else fail the checking Validation depends on Class AccountDAO /// get the passwords hash result from DAO AccountDAO dao = new AccountDao(); String passwordHashFromDAO = dao.getPasswordHash(id); Validation depends on Class Hash /// get the ids hash result from Hash Hash hash = new Hash(); String hashResult = hash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Problem ? (2/3) It violates the OCP (Open Closed Principle) If we want to mock AccountDAO & Hash, we must modify the code in class of Validation. /// pseudo code for CheckAuthentication /// input: string id /// input: string password /// output: true --> if pass the checking /// false --> else fail the checking /// get the passwords hash result from DAO AccountDAO dao = new AccountDao(); String passwordHashFromDAO = dao.getPasswordHash(id); /// get the ids hash result from Hash Hash hash = new Hash(); String hashResult = hash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Problem ? (3/3) Now, you can upgrade your AccountDAO & Hash without modifying the class of Validation. (If you just want to test, mock it.)這個把初始化動作,由原本目標物件內,轉移到目標物件之外, /// pseudo code for CheckAuthentication稱作「控制反轉 控制反轉」,也就是IoC。 控制反轉 /// input: string id /// input: string password /// output: true --> if pass the checking /// false --> else fail the checking /// get the passwords hash result from DAO這個把依賴的物件,透過目標物件公開建構式,交給外 AccountDAO dao = new AccountDao();部來決定,稱作「依賴注入 依賴注入」,也就是DI。 依賴注入 String passwordHashFromDAO = mDao.getPasswordHash(id); /// get the ids hash result from Hash Hash hash = new Hash(); String hashResult = mHash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Definition for IoC & DI• Inversion of Control [IoC] (from wiki) o An object-oriented programming practice where the object coupling is bound at run time by an assembler object and it typically not known at compile time using static analysis. o Usually used in Unit Test to do the isolation test.• Dependency Injection [DI] (from wiki) o A software design pattern that allows a choice of component to be made at run-time rather than compile time.
    • Method to make your SW testable (1)• Constructor• Public Setter• Pass Arguments• Inheritance
    • Method to make your SW testable (2)• Constructor [used in the previous slides]• Public Setter• Pass Arguments• Inheritance
    • Method to make your SW testable (3)• Constructor• Public Setter• Pass Arguments• Inheritance
    • Method to make your SW testable (4) Set the dependency object via public setter /// pseudo code for CheckAuthentication /// input: string id /// input: string password /// output: true --> if pass the checking /// false --> else fail the checking /// get the passwords hash result from DAO AccountDAO dao = new AccountDao(); String passwordHashFromDAO = mDao.getPasswordHash(id); /// get the ids hash result from Hash Hash hash = new Hash(); String hashResult = mHash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Method to make your SW testable (5)• Constructor• Public Setter• Pass Arguments• Inheritance
    • Method to make your SW testable (6) /// pseudo code for CheckAuthentication /// input: string id /// input: string password /// input: Hash hash /// input: AccountDAO dao /// output: true --> if pass the checking /// false --> else fail the checking /// get the passwords hash result from DAO AccountDAO dao = new AccountDao(); String passwordHashFromDAO = dao.getPasswordHash(id); /// get the ids hash result from Hash Hash hash = new Hash(); String hashResult = hash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Method to make your SW testable (7)• Constructor• Public Setter• Pass Arguments• Inheritance
    • Method to make your SW testable (8) Use the subclass to do the UT. Override the getter to mock objects. /// pseudo code for CheckAuthentication /// input: string id /// input: string password /// output: true --> if pass the checking /// false --> else fail the checking /// get the passwords hash result from DAO AccountDAO dao = getAccountDAO(); String passwordHashFromDAO = dao.getPasswordHash(id); /// get the ids hash result from Hash Hash hash = getHash(); String hashResult = hash.getHashResult(password); /// check the result return passwordHashFromDAO.equals(hashResult);
    • Compare these ways Method Name Cons Pros 由建構式傳入相依介面的實體物件,是一個 與原本直接相依的程式碼相比較,目標物件的Constructor 很通用的方式。因此在結合許多常見的DI 相依物件因此暴露出來,交由外部決定,而喪 framework,不需要在額外處理。 失了一點封裝的意味。 同樣的,public property也是常見的 最常見的情況,就是使用目標物件時,相依介Public Setter dependency injection points,所以 面應有其對應執行個體,但卻因為使用端沒有 也有許多DI framework支援。另外則是不 設定public property,導致使用方法時出 需要對建構式進行改變,或增加新的建構式 現NullReferenceException,這種情況也 。對過去已經存在的legacy code的影響, 怪不了使用端,因為使用端極有可能本就不瞭 會比建構式的方式小一點點(但幾乎沒有太 解這個方法中,有哪些相依物件 大差異) 不必再擔心要先初始化哪些property,或 最大的問題,在於方法簽章上的不穩定性。當Pass Arguments 呼叫哪一個建構式。當要呼叫某一個方法, 需求異動,該方法需要額外相依於其他物件時 其相依的物件,就是得透過參數來給定。基 ,方法簽章可能會被迫改變。而方法簽章是物 本上也不太需要擔心使用上造成困擾或迷惑 件導向設計上,最需要穩定的條件之一。以物 件導向、介面導向設計來說,當多型物件方法 簽章不一致時,向來是個大問題。 這個方式最大的好處,是完全不影響外部使 這是為了測試,且legacy code所使用的方式Inheritance 用物件的方式。僅透過protected與 ,而不是良好的物件導向設計的方式。IoC的 virtual來對繼承鏈開放擴充的功能,並且 用意在於介面導向與擴充點的彈性,所以當可 透過這樣的方式,就使得原本直接相依而導 測試之後,倘若重構影響範圍不大,建議讀者 致無法測試的問題,獲得解套。 朋友還是要將物件改相依於介面,透過IoC的 方式來設計物件。