Как да направите модулно тестване в Microsoft Dynamics AX 2012 в проект от реалния свят

Съгласен съм, че създаването на тестови данни в нова и празна компания работи само за сравнително тривиални сценарии или сценарии, при които сами сте внедрили цялата структура на данните. Но веднага щом са необходими съществуващи структури от данни, този подход може да отнеме много време.

Един подход, който работеше добре за мен в миналото, е да изпълнявам модулни тестове в съществуваща компания, която вече разполага с повечето конфигурационни данни (напр. финансова настройка, настройка на инвентара, ...), необходими за провеждане на теста. Самият тест се изпълнява в блок ttsBegin - ttsAbort, така че единичният тест всъщност не създава никакви данни.

Друг подход е да се приложат методи на доставчик на данни, които са тестови агностици, но създават данни, които често се използват в единични тестове (напр. метод, който създава продукт). Отнема известно време, за да се създаде полезен набор от методи за доставчик на данни, но след като те съществуват, писането на модулни тестове става много по-бързо. Вижте SysTest част V.: Изпълнение на теста (резултати, участници и слушатели) за това как Microsoft използва подобен подход (или поне през 2007 г. за AX 4.0).

И двата подхода могат също да се комбинират, бихте извикали методите на доставчика на данни вътре в блока ttsBegin - ttsAbort, за да създадете необходимите данни само за единичния тест.

Друг полезен метод е да използвате doInsert или doUpdate за създаване на вашите тестови данни, особено ако се интересувате само от няколко полета и не е необходимо да създавате напълно валиден запис.

Мисля, че рамката за единичен тест беше последваща мисъл. За да го използва наистина, Microsoft би трябвало да предостави модулни тестови класове, след което, когато персонализирате техния код, вие също персонализирате техните модулни тестове.

Така че без това вие по същество оставате да кодирате единични тестове, които се опитват да обхванат основния код заедно с вашите модификации, което е огромна задача.

Мисля, че всъщност можете да го използвате около изолирани персонализации, които изпълняват някаква функция и не са силно изградени върху основен код. А също и с персонализации, които са интеграции с външни системи.

Е, от моя гледна точка няма да можете да използвате повече от това, което посочихте от стандартната рамка. Това, което можете да направите, е повече около управлението на изданията. Можете да настроите интеграционна среда с целевите данни и да поставите своя модел за нощно изграждане в тази среда в края на процеса на изграждане и след това да изпълните вашите тестове. Да, ще са необходими повече усилия, за да го настроите и поддържате, но това е единственото решение, което съм виждал досега, за да има голям и последователен набор от данни, върху които да се изпълняват единици или интеграционни тестове.

За да има смислени тестове, трябва да се предоставят някои тестови данни (съхранени в таблици в базата данни).

Както някой друг вече посочи - намерих за най-добре да използвам съществуваща компания за данни. В моя случай няколко съществуващи компании.

За да получим възпроизводим резултат от единичните тестове, трябва да имаме едни и същи данни, съхранявани в таблиците всеки път, когато тестовете се изпълняват. Сега въпросът е как можем да постигнем това?

Създадохме помощни средства за тестване, които ни помагат да "изпълним теста", автоматизирайки това, което би направил човек - ако сте проектирали приложението си така, че да може да се тества. По същество нашият тестов клас използва помощниците, за да изпълни теста, след което предоставя по-голямата част от стойността при валидирането на създадените от него данни.

Научих, че има възможност за задаване на нивото на изолация за TestSuite на SysTestSuiteCompanyIsolateClass. Това ще създаде празна компания и ще изтрие компанията след провеждане на тестовете. В метода setup() мога да попълня моите тестови данни в таблиците с изрази за вмъкване. Това работи добре за малки сценарии, но става много тромаво, ако имате реален проект.

Не намерих това за практично в нашата ситуация, така че не сме го използвали.

Чудех се дали има някой с практическо решение как да използвам X++ Unit Test Framework в сценарий от реалния свят. Всеки принос е много ценен.

Използвахме рамката за тестване, както е посочено по-горе, и тя работи за нас. ключът е да се намерят правилните сценарии за тестване, също така предоставя добра основа за писане на тествани класове.