BDD і звонку ў падыходзе, як пачаць з тэставаннем

усе,

Я спрабую зразумець усе па-за-у TDD і BDD рэчы і хацеў бы, каб вы дапамаглі мне, каб атрымаць яго.

Дапусцім, мне трэба рэалізаваць Config Parameters функцыянальнасць працаваць наступным чынам:

  • ёсць параметры ў файле і ў базе дадзеных
  • абедзве групы павінны быць аб'яднаны ў адзін набор параметраў
  • <Літый> параметры з базы дадзеных павінны перавызначыць тыя з файлаў

Цяпер я хацеў бы рэалізаваць гэта з вонкавым ў падыходзе, і я затрымаўся толькі ў самым пачатку. Спадзяюся, што вы можаце дапамагчы мне, каб атрымаць рух. Мае пытанні:

Які тэст я павінен пачаць? Я проста н наступным чынам:

class ConfigurationAssemblerTest {

    @Test
    public void itShouldResultWithEmptyConfigurationWhenBothSourcesAreEmpty() {
        ConfigurationAssembler assembler = new ConfigurationAssembler();            
       //what to put here ?
        Configuration config = assembler.getConfiguration();            
        assertTrue(config.isEmpty());
    }

}

Я яшчэ не ведаю, што залежнасці я скончу. Я не ведаю, як я буду пісаць усё, што матэрыял яшчэ і гэтак далей. Тое, што я павінен паставіць у гэтым цесцю, каб зрабіць яго сапраўдным? Ці павінен я здзекавацца-то? Калі гэта так, як вызначыць гэтую залежнасць?

Калі б вы, калі ласка, пакажы мне шлях, каб пайсці з гэтым, напісаць які-небудзь план, некаторыя тэсты шкілетаў, што рабіць і ў якім парадку ён быў бы супер-крута. Я ведаю, што шмат пісаць, так што, можа быць, вы можаце паказаць мне на якія-небудзь рэсурсы? Усе рэсурсы аб па-за-ў падыходзе я знайшоў былі аб простых выпадках без якіх-небудзь залежнасцяў і г.д.

І два пытаньні да кплівым падыходу.

  • калі насмешлівы аб узаемадзеянні і іх верыфікацыі, гэта значыць, што не павінна быць дзяржаўнымі сцвярджэнняў ў такіх выпрабаваннях (толькі пераймаюць паверкі)?
  • калі замяніць тое, што яшчэ не існуе з здзекавацца толькі для тэставання, мы заменім яго пазней з рэальнай версіяй?

Загадзя дзякую.

1

1 адказы

Добра, што на самой справе вельмі шмат рэчаў. Давайце пачнем з канца:

  • Mocking is not only about 'interactions and their verification', this would be only one half of the story. In fact, you're using it in two different ways:

    1. Checking, if a certain call was made, and eventually also checking the arguments of the call (this is the 'interactions and verification' part).

    2. Using mocks to replace dependencies of the class-under-test (CUT), eventually setting up return values on the mock objects as required. Here, you use mock objects to isolate the CUT from the rest of the system (so that you can handle the CUT as an isolated 'unit', which sort of runs in a sandbox).

Я б назваў першую форму дынамічнай або «ўзаемадзеянне на аснове» модульнага тэставання, ён выкарыстоўвае насмешлівыя рамкі выкліку метадаў праверкі. Другі адзін больш традыцыйнае «статычнае» модульнае тэставанне, якое сцвярджае факт.

  • Вы ніколі не павінны мець неабходнасць «замяніць тое, што яшчэ не існуе» (за выключэннем таго факту, што гэта - лагічна відаць - цалкам немагчыма). Калі вы адчуваеце, што вам трэба зрабіць гэта, то гэта відавочная прыкмета таго, што вы спрабуеце зрабіць другі крок перад першым.

  • Што тычыцца вашага паняцця "па-за-падыходу»: Шчыра кажучы, я ніколі не чуў пра гэта раней, так што гэта, здаецца, не будзе вельмі прыкметным паняцце - і, відавочна, не вельмі карысна адзін , таму што здаецца, пераблытаць рэчы больш, чым тлумачэнне іх (па меншай меры на дадзены момант).

Цяпер на ваш першы пытанне: ( Які тэст я павінен пачаць з ?):

  1. First things first - you need some mechanism to read the configuration values from file and database, and this functionality should be encapsulated in separate helper classes (you need, among other things, a clean Separation of concerns for effectively doing TDD - this usually is totally underemphasized when introducing TDD/BDD). I'd suggest an interface (e.g. IConfigurationReader) which has two implementations (one for the file stuff and one for the database, e.g. FileConfigurationReader and DatabaseConfigurationReader). In TDD (not necessarily with a BDD approach) you would also have corresponding test fixtures. These fixtures would cover test cases like 'What happens if the underlying data store contains no/invalid/valid/other special values?'. This is what I'd advice you to start with.

  2. Only then - with the reading mechanism in operation and your ConfigurationAssembler class having the necessary dependencies - you would start to write tests for/implement the ConfigurationAssembler class. Your test then could look like this (Because I'm a C#/.NET guy, I don't know the appropriate Java tools. So I'm using pseudo-code here):

    class ConfigurationAssemblerTest {

    @Test
    public void itShouldResultWithEmptyConfigurationWhenBothSourcesAreEmpty() {
    
        IConfigurationReader fileConfigMock = new [Mock of FileConfigurationReader];
        fileConfigMock.[WhenAskedForConfigValues].[ReturnEmpty];
    
        IConfigurationReader dbConfigMock = new [Mock of DatabaseConfigurationReader];
        dbConfigMock.[WhenAskedForConfigValues].[ReturnEmpty];
    
        ConfigurationAssembler assembler = new ConfigurationAssembler(fileConfigMock, dbConfigMock);            
    
        Configuration config = assembler.getConfiguration();            
    
        assertTrue(config.isEmpty());
    }
    

    }

Дзве рэчы важныя тут:

  • <р> Два аб'екта чытача ўводзяць у ConfigurationAssembler звонку з дапамогай свайго канструктара - гэты метад выклікаецца Dependency Injection . Гэта вельмі карысна і важна архітэктурны прынцып, як правіла, прыводзіць да лепшай і больш чыстай архітэктуры (і вельмі дапамагае ў модульным тэставанні, асабліва пры выкарыстанні фіктыўных аб'ектаў).

  • <р> Тэст Цяпер сцвярджае, што менавіта ён абвяшчае: ConfigurationAssembler вяртае ( «мантуе») пусты канфігурацыі, калі базавыя механізмы чытання са свайго боку, вяртае пусты выніковы набор. І таму, што мы выкарыстоўваем фіктыўныя аб'екты для забеспячэння значэння канфігурацыі, тэст выконваецца ў поўнай ізаляцыі. Мы можам быць упэўнены, што мы тэстуем толькі правільнае функцыянаванне ConfigurationAssembler клас (яго апрацоўка пустых значэнняў, а менавіта), і нічога іншага.

Так, і, можа быць, гэта прасцей для вас, каб пачаць з TDD замест BDD, таму што BDD толькі падмноства TDD і будуе на вяршыні канцэпцый TDD. Такім чынам, вы можаце зрабіць толькі (і разумець) BDD эфектыўна, калі вы ведаеце TDD.

НТН!

1
дададзена