පුද්ගලික ශ්‍රිතයක් හෝ පුද්ගලික ක්‍රම, ක්ෂේත්‍ර හෝ අභ්‍යන්තර පන්ති ඇති පන්තියක් පරීක්ෂා කරන්නේ කෙසේද?

අභ්‍යන්තර පුද්ගලික ක්‍රම, ක්ෂේත්‍ර හෝ කැදැලි පන්ති ඇති පන්තියක් (xUnit භාවිතා කරමින්) ඒකක පරීක්‍ෂා කරන්නේ කෙසේද? හෝ අභ්‍යන්තර සම්බන්ධතා ( staticC / C ++ වලින්) මගින් පුද්ගලික කර ඇති ශ්‍රිතයක්ද නැතහොත් පුද්ගලික ( නිර්නාමික ) නාම අවකාශයක තිබේද?

පරීක්ෂණයක් පවත්වා ගෙන යාම සඳහා ක්‍රමයක් හෝ ශ්‍රිතයක් සඳහා ප්‍රවේශ විකරණකාරකය වෙනස් කිරීම නරක යැයි පෙනේ.

යාවත්කාලීන කිරීම:

අවුරුදු 10 පසුව සමහර විට පෞද්ගලික ක්රමය, හෝ ඕනෑම ඇද හැලුණු සාමාජික පරීක්ෂා කිරීමට හොඳම ක්රමය, හරහා වේ @Jailbreakසිට නානාප්රකාර රාමුව.

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

මේ ආකාරයෙන් ඔබේ කේතය ටයිප්-ආරක්ෂිත සහ කියවිය හැකි ලෙස පවතී. පරීක්ෂණ සඳහා නිර්මාණ සම්මුතියක් නැත, අධික ලෙස නිරාවරණය වන ක්‍රම සහ ක්ෂේත්‍ර නොමැත.

ඔබට තරමක් පැරණි ජාවා යෙදුමක් තිබේ නම් සහ ඔබේ ක්‍රමවල දෘශ්‍යතාව වෙනස් කිරීමට ඔබට ඉඩ නොදෙන්නේ නම්, පුද්ගලික ක්‍රම පරීක්ෂා කිරීමට හොඳම ක්‍රමය පරාවර්තනය භාවිතා කිරීමයි .

අභ්‍යන්තරව අපි උදව්කරුවන් භාවිතා කරන්නේ / සැකසීමට privateසහ private staticවිචල්‍යයන් මෙන්ම ආයාචනා privateසහ private staticක්‍රම ලබා ගැනීමට ය. පහත දැක්වෙන රටා මඟින් පුද්ගලික ක්‍රම සහ ක්ෂේත්‍ර හා සම්බන්ධ ඕනෑම දෙයක් කිරීමට ඔබට ඉඩ සලසයි. ඇත්ත වශයෙන්ම, ඔබට private static finalපරාවර්තනය හරහා විචල්යයන් වෙනස් කළ නොහැක .

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

සහ ක්ෂේත්‍ර සඳහා:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

සටහන්:
1. ක්‍රම TargetClass.getDeclaredMethod(methodName, argClasses)සොයා බැලීමට ඔබට ඉඩ සලසයි private. එකම දෙය අදාළ වේ getDeclaredField.
2. පුද්ගලිකයන් setAccessible(true)සමඟ සෙල්ලම් කිරීම අවශ්‍ය වේ.

පුද්ගලික ක්‍රමයක් පරීක්ෂා කිරීමට හොඳම ක්‍රමය වෙනත් පොදු ක්‍රමයක් හරහා ය. මෙය කළ නොහැකි නම්, පහත දැක්වෙන කොන්දේසි වලින් එකක් සත්‍ය වේ:

1. පුද්ගලික ක්‍රමය වන්නේ මළ කේතයයි
2. ඔබ පරීක්ෂා කරන පන්තිය අසල නිර්මාණ සුවඳක් ඇත
3. ඔබ පරීක්ෂා කිරීමට උත්සාහ කරන ක්‍රමය පුද්ගලික නොවිය යුතුය

පංතියක මට පෞද්ගලික ක්‍රම ඇති විට ප්‍රමාණවත් තරම් සංකීර්ණ වන අතර පුද්ගලික ක්‍රම කෙලින්ම පරීක්ෂා කිරීමේ අවශ්‍යතාවය මට දැනේ, එය කේත සුවඳකි: මගේ පන්තිය ඉතා සංකීර්ණයි.

එවැනි ගැටළු විසඳීම සඳහා මගේ සුපුරුදු ප්‍රවේශය නම් සිත්ගන්නා සුළු බිටු අඩංගු නව පන්තියක් විහිළු කිරීමයි. බොහෝ විට, මෙම ක්‍රමය සහ එය අන්තර්ක්‍රියා කරන ක්ෂේත්‍ර, සමහර විට වෙනත් ක්‍රමයක් හෝ දෙකක් නව පන්තියකට උකහා ගත හැකිය.

නව පංතිය මෙම ක්‍රම 'පොදු' ලෙස නිරාවරණය කරයි, එබැවින් ඒවා ඒකක පරීක්ෂණ සඳහා ප්‍රවේශ විය හැකිය. නව සහ පැරණි පංති දැන් මුල් පන්තියට වඩා සරල ය, එය මට ඉතා සුදුසු ය (මට දේවල් සරල ලෙස තබා ගත යුතුය, නැතහොත් නැති වී යයි!).

මිනිසුන්ගේ මොළය භාවිතා නොකර පන්ති නිර්මාණය කරන ලෙස මම යෝජනා නොකරන බව සලකන්න! මෙහි ඇති කාරණය නම් හොඳ නව පන්ති සොයා ගැනීමට ඔබට උපකාර කිරීම සඳහා ඒකක පරීක්ෂණ බලයන් භාවිතා කිරීමයි.

මම අතීතයේ දී ජාවා සඳහා මෙය කිරීමට පරාවර්තනය භාවිතා කර ඇති අතර මගේ මතය අනුව එය විශාල වැරැද්දකි.

නිශ්චිතවම කිවහොත්, ඔබ පෞද්ගලික ක්‍රම කෙලින්ම පරීක්ෂා කරන ඒකක පරීක්ෂණ ලිවිය යුතු නොවේ . ඔබ පරීක්ෂා කළ යුත්තේ පන්තිය වෙනත් වස්තූන් සමඟ ඇති පොදු ගිවිසුමයි; ඔබ කිසි විටෙකත් වස්තුවක අභ්‍යන්තරය කෙලින්ම පරීක්ෂා නොකළ යුතුය. පංතියේ පොදු කොන්ත්‍රාත්තුවට බල නොපාන වෙනත් සංවර්ධකයෙකුට පන්තියේ කුඩා අභ්‍යන්තර වෙනසක් කිරීමට අවශ්‍ය නම්, ඔහු / ඇය ඔබේ පරාවර්තන පදනම් කරගත් පරීක්ෂණය වෙනස් කර එය ක්‍රියාත්මක වන බව සහතික කළ යුතුය. ඔබ මෙය ව්‍යාපෘතියක් පුරා නැවත නැවතත් කරන්නේ නම්, ඒකක පරීක්ෂණ පසුව කේත සෞඛ්‍යය පිළිබඳ ප්‍රයෝජනවත් මිනුමක් වීම නවතා දමා සංවර්ධනයට බාධාවක් වන අතර සංවර්ධන කණ්ඩායමට කරදරයක් වනු ඇත.

ඒ වෙනුවට මම නිර්දේශ කරන්නේ කොබර්ටුරා වැනි කේත ආවරණ මෙවලමක් භාවිතා කිරීම, ඔබ ලියන ඒකක පරීක්ෂණ මඟින් පුද්ගලික ක්‍රමවේදයන් තුළ කේතයේ හොඳ ආවරණයක් ලබා දෙන බව සහතික කිරීමයි. ඒ ආකාරයෙන්, ඔබ පෞද්ගලික ක්‍රමවේදයන් කරන්නේ කුමක්ද යන්න වක්‍රව පරික්ෂා කර, ඉහළ මට්ටමේ ක්‍රියාශීලී බවක් පවත්වා ගනී.

මෙම ලිපියෙන්: ජුනිට් සහ සූට් රන්නර් (බිල් වෙනර්ස්) සමඟ පුද්ගලික ක්‍රම පරීක්ෂා කිරීම , ඔබට මූලික වශයෙන් විකල්ප 4 ක් ඇත:

1. පුද්ගලික ක්‍රම පරීක්ෂා නොකරන්න.
2. ක්‍රම පැකේජයට ප්‍රවේශය දෙන්න.
3. කැදැලි පරීක්ෂණ පන්තියක් භාවිතා කරන්න.
4. පරාවර්තනය භාවිතා කරන්න.

සාමාන්‍යයෙන් ඒකක පරීක්ෂණයක් යනු පන්තියක හෝ ඒකකයක පොදු අතුරු මුහුණත ක්‍රියාත්මක කිරීමයි. එබැවින්, පුද්ගලික ක්‍රම යනු ඔබ පැහැදිලිව පරීක්ෂා කිරීමට අපේක්ෂා නොකරන ක්‍රියාත්මක කිරීමේ විස්තර වේ.

මට පෞද්ගලික ක්‍රමයක් පරීක්ෂා කිරීමට අවශ්‍ය තැනට උදාහරණ දෙකක් පමණි:

1. විකේතන චර්යාවන් - ඒවා පරීක්ෂා කිරීම සඳහා පමණක් කිසිවෙකුට දැකීමට මා කැමති නැත, එසේ නොමැතිනම් ඕනෑම කෙනෙකුට ඒවා විකේතනය කිරීමට භාවිතා කළ හැකිය. නමුත් ඒවා කේතයට ආවේනික වන අතර සංකීර්ණ වන අතර සෑම විටම ක්‍රියා කිරීමට අවශ්‍ය වේ (පැහැදිලිවම ව්‍යතිරේකය යනු මෙය SecurityManagerවැළැක්වීම සඳහා වින්‍යාසගත කර නොමැති විට බොහෝ අවස්ථාවන්හිදී පුද්ගලික ක්‍රම පවා බැලීමට භාවිතා කළ හැකි පරාවර්තනයයි ).
2. ප්‍රජා පරිභෝජනය සඳහා SDK නිර්මාණය කිරීම . මෙහි දී පොදු ලෝකය මුළුමනින්ම වෙනස් අර්ථයක් ගනී, මෙය මුළු ලෝකයම දැකිය හැකි කේතයක් බැවින් (මගේ යෙදුමට අභ්‍යන්තරව පමණක් නොවේ). SDK භාවිතා කරන්නන් එය දැකීමට මා අකමැති නම් මම කේතය පුද්ගලික ක්‍රමවලට ඇතුළත් කරමි - මෙය කේත සුවඳක් ලෙස මා දකින්නේ නැත, හුදෙක් SDK ක්‍රමලේඛනය ක්‍රියා කරන ආකාරය ලෙස. නමුත් ඇත්ත වශයෙන්ම මට තවමත් මගේ පෞද්ගලික ක්‍රම පරීක්ෂා කිරීමට අවශ්‍ය වන අතර ඒවා මගේ SDK හි ක්‍රියාකාරිත්වය සැබවින්ම ජීවත්වන ස්ථානයයි.

"කොන්ත්රාත්තුව" පමණක් පරීක්ෂා කිරීමේ අදහස මට වැටහේ. නමුත් කෙනෙකුට කේත පරීක්ෂා නොකිරීමට උපදෙස් දිය හැකි බව මම නොදනිමි - ඔබේ සැතපුම් ගණන වෙනස් විය හැකිය.

එබැවින් මගේ වෙළඳාමට ඇතුළත් වන්නේ මගේ ආරක්ෂාව සහ එස්ඩීකේ සම්මුතියකට වඩා ජුනිට්ස් පරාවර්තනය සමඟ සංකීර්ණ කිරීමයි.

පුද්ගලික ක්‍රම පොදු ක්‍රමයක් මගින් කැඳවනු ලැබේ, එබැවින් ඔබේ පොදු ක්‍රමවේදයන් සඳහා වන යෙදවුම් එම පොදු ක්‍රම මගින් හඳුන්වන පුද්ගලික ක්‍රම පරීක්ෂා කළ යුතුය. පොදු ක්‍රමයක් අසමත් වූ විට එය පෞද්ගලික ක්‍රමයේ අසාර්ථක විය හැකිය.

මා භාවිතා කළ තවත් ප්‍රවේශයක් නම් පුද්ගලික හෝ ආරක්‍ෂිත ඇසුරුම් කිරීම සඳහා පුද්ගලික ක්‍රමයක් වෙනස් කිරීම සහ ගූගල් ගුවා පුස්තකාලයේ isVisibleForTesting ව්‍යාඛ්‍යාව සමඟ එය සම්පුර්ණ කිරීමයි.

මෙම ක්‍රමය භාවිතා කරන ඕනෑම කෙනෙකුට ප්‍රවේශම් වන ලෙසත් පැකේජයක් තුළ පවා එය කෙලින්ම ප්‍රවේශ නොවන ලෙසත් මෙය කියනු ඇත. පරීක්ෂණ පන්තියක් භෞතිකව එකම පැකේජයක නොව පරීක්ෂණ ෆෝල්ඩරය යටතේ එකම පැකේජයක තිබිය යුතුය .

උදාහරණයක් ලෙස, පරීක්ෂා කළ යුතු ක්‍රමයක් තිබේ src/main/java/mypackage/MyClass.javaනම් ඔබේ පරීක්ෂණ ඇමතුම තැබිය යුතුය src/test/java/mypackage/MyClassTest.java. ඒ ආකාරයෙන්, ඔබේ පරීක්ෂණ පන්තියේ පරීක්ෂණ ක්‍රමයට ඔබට ප්‍රවේශය ලැබුණි.

විශාල හා විචක්ෂණශීලී පංති සමඟ උරුම කේතය පරීක්ෂා කිරීම සඳහා, මම දැන් ලියන එක් පුද්ගලික (හෝ පොදු) ක්‍රමයක් පරීක්ෂා කිරීමට හැකිවීම බොහෝ විට ඉතා ප්‍රයෝජනවත් වේ .

මම ජාවා සඳහා junitx.util.PrivateAccessor -package භාවිතා කරමි . පුද්ගලික ක්‍රම සහ පුද්ගලික ක්ෂේත්‍ර වෙත ප්‍රවේශ වීම සඳහා ප්‍රයෝජනවත් එක්-ලයිනර් ගොඩක්.

import junitx.util.PrivateAccessor;

PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

තුළ වසන්තය රාමුව ඔබ මෙම ක්රමය භාවිතා පෞද්ගලික ක්රම පරීක්ෂා කළ හැක:

ReflectionTestUtils.invokeMethod()

උදාහරණයක් වශයෙන්:

ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

ජාවා සඳහා පරාවර්තනය භාවිතා කරමින් සෙම් කැටිකස්ගේ විසඳුම අත්හදා බැලීමෙන් පසුව , මම මෙහි විස්තර කර ඇතිවාට වඩා ඔහුගේ අලංකාර විසඳුම යැයි පැවසිය යුතුය. කෙසේ වෙතත්, ඔබ පරාවර්තනය භාවිතා කිරීමට විකල්පයක් සොයන්නේ නම් සහ ඔබ පරීක්ෂා කරන ප්‍රභවයට ප්‍රවේශය තිබේ නම්, මෙය තවමත් විකල්පයක් වනු ඇත.

කිසියම් කේතයක් ලිවීමට පෙර කුඩා පරීක්ෂණ සැලසුම් කිරීමට ඔබ කැමති තැනක , විශේෂයෙන් පරීක්‍ෂණයෙන් මෙහෙයවන ලද සංවර්ධනයක් සහිතව, පන්තියක පෞද්ගලික ක්‍රමවේදයන් පරීක්‍ෂා කිරීමේ කුසලතාවයක් ඇත .

පුද්ගලික සාමාජිකයින්ට සහ ක්‍රමවේදයන්ට ප්‍රවේශයක් සහිත පරීක්ෂණයක් නිර්මාණය කිරීමෙන් පොදු ක්‍රමවලට පමණක් ප්‍රවේශ වීමත් සමඟ නිශ්චිතවම ඉලක්ක කිරීමට අපහසු කේත ක්ෂේත්‍ර පරීක්ෂා කළ හැකිය. පොදු ක්‍රමයකට පියවර කිහිපයක් සම්බන්ධ වී ඇත්නම්, එය පෞද්ගලික ක්‍රම කිහිපයකින් සමන්විත විය හැකි අතර ඒවා තනි තනිව පරීක්ෂා කළ හැකිය.

වාසි:

• සියුම් කැටි ගැසීමක් පරීක්ෂා කළ හැකිය

අවාසි:

• පරීක්ෂණ කේතය ප්‍රභව කේත ලෙස එකම ගොනුවක තිබිය යුතු අතර එය නඩත්තු කිරීමට වඩා අපහසු විය හැකිය
• .Class ප්‍රතිදාන ලිපිගොනු සමඟ, ඒවා ප්‍රභව කේතයේ ප්‍රකාශ කර ඇති පැකේජයේම පැවතිය යුතුය

කෙසේ වෙතත්, අඛණ්ඩ පරීක්ෂණ සඳහා මෙම ක්‍රමය අවශ්‍ය නම්, එය සාම්ප්‍රදායික, පොදු ආකාරයෙන් පරීක්ෂා කළ හැකි පුද්ගලික ක්‍රම උපුටා ගත යුතු බවට සං signal ාවක් විය හැකිය.

මෙය ක්‍රියාත්මක වන්නේ කෙසේද යන්න පිළිබඳ සංක්ෂිප්ත උදාහරණයක් මෙන්න:

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

අභ්‍යන්තර පන්තිය සම්පාදනය කෙරේ ClassToTest$StaticInnerTest.

මෙයද බලන්න: ජාවා ඉඟිය 106: විනෝදය සහ ලාභය සඳහා ස්ථිතික අභ්‍යන්තර පන්ති

අනෙක් අය පවසා ඇති පරිදි ... පුද්ගලික ක්‍රම කෙලින්ම පරීක්ෂා නොකරන්න. සිතුවිලි කිහිපයක් මෙන්න:

1. සියලුම ක්‍රම කුඩා හා අවධානයෙන් තබා ගන්න (පරීක්ෂා කිරීමට පහසුය, වැරදි දේ සොයා ගැනීමට පහසුය)
2. කේත ආවරණ මෙවලම් භාවිතා කරන්න. මම කොබර්ටුරාට කැමතියි (ඔහ් ප්‍රීතිමත් දවසක්, නව අනුවාදයක් ඉවරයි වගේ !)

ඒකක පරීක්ෂණ වලදී කේත ආවරණය ක්‍රියාත්මක කරන්න. ක්‍රම සම්පුර්ණයෙන්ම පරීක්‍ෂා කර නොමැති බව ඔබ දුටුවහොත් ආවරණය ඉහළ නැංවීම සඳහා පරීක්ෂණවලට එක් කරන්න. 100% කේත ආවරණය සඳහා ඉලක්කය, නමුත් ඔබට එය නොලැබෙන බව තේරුම් ගන්න.

පුද්ගලික ක්‍රම මහජනතාව විසින් පරිභෝජනය කරනු ලැබේ. නැතිනම් ඒවා මළ කේතයකි. පොදු ක්‍රමයේ අපේක්ෂිත ප්‍රති results ල සහ එමඟින් එය පරිභෝජනය කරන පුද්ගලික ක්‍රමවේදයන් තහවුරු කරමින් ඔබ පොදු ක්‍රමය පරීක්ෂා කරන්නේ එබැවිනි.

පොදු ක්‍රම පිළිබඳ ඔබේ ඒකක පරීක්ෂණ ක්‍රියාත්මක කිරීමට පෙර පුද්ගලික ක්‍රම පරීක්ෂා කිරීම නිදොස් කිරීම මඟින් පරීක්ෂා කළ යුතුය.

ඔබේ සියලු ප්‍රකාශයන් ඉටු වන තුරු ඒවා පරීක්‍ෂා කරන ලද සංවර්ධනයක් භාවිතයෙන් දෝශ නිරාකරණය කළ හැකිය.

TDD භාවිතා කරමින් පන්ති නිර්මාණය කිරීම වඩා හොඳ යැයි මම පෞද්ගලිකව විශ්වාස කරමි; කල්තියා නිර්වචනය කර ඇති සියලු ප්‍රකාශයන් සමඟ ඒකක පරීක්ෂණ උත්පාදනය කිරීම , එමඟින් ඔබ එය කේත කිරීමට පෙර ක්‍රමයේ අපේක්ෂිත ප්‍රති come ල තීරණය වේ. මේ ආකාරයෙන්, ඒකක පරීක්ෂණ ප්‍රකාශයන් ප්‍රති .ලවලට ගැලපෙන පරිදි වැරදි මාවතකට නොයන්න. එවිට ඔබේ පන්තිය ශක්තිමත් වන අතර ඔබේ සියලු ඒකක පරීක්ෂණ සමත් වූ විට අවශ්‍යතා සපුරාලයි.

වසන්තය භාවිතා කරන්නේ නම්, පරාවර්තනය ටෙස්ට් යූටිල්ස් විසින් අවම උත්සාහයකින් මෙහි උපකාරී වන මෙවලම් කිහිපයක් සපයයි. නිදසුනක් වශයෙන්, නුසුදුසු පොදු කට්ටලයක් එක් කිරීමට බල නොකර පුද්ගලික සාමාජිකයෙකුට සරදම් කිරීම:

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

ඔබ අකමැති හෝ වෙනස් කිරීමට නොහැකි වූ පවතින කේතය පරීක්ෂා කිරීමට උත්සාහ කරන්නේ නම්, පරාවර්තනය හොඳ තේරීමකි.

පංතියේ සැලසුම තවමත් නම්‍යශීලී නම් සහ ඔබට වෙනමම පරීක්ෂා කිරීමට අවශ්‍ය සංකීර්ණ පෞද්ගලික ක්‍රමයක් තිබේ නම්, මම ඔබට යෝජනා කරන්නේ එය වෙනම පන්තියකට ඇදගෙන එම පන්තිය වෙන වෙනම පරීක්ෂා කරන්න. මෙය මුල් පන්තියේ පොදු අතුරු මුහුණත වෙනස් කළ යුතු නැත; එයට අභ්‍යන්තරව උපකාරක පන්තියේ නිදසුනක් නිර්මාණය කළ හැකි අතර සහායක ක්‍රමය අමතන්න.

උපකාරක ක්‍රමයෙන් එන දුෂ්කර දෝෂ තත්වයන් පරීක්ෂා කිරීමට ඔබට අවශ්‍ය නම්, ඔබට තවත් පියවරක් ඉදිරියට යා හැකිය. උපකාරක පන්තියෙන් අතුරු මුහුණතක් උපුටා ගැනීම, සහායක පන්තියට එන්නත් කිරීම සඳහා මුල් පන්තියට පොදු ගැටුමක් සහ සැකසුම් එකතු කරන්න (එහි අතුරුමුහුණත හරහා භාවිතා වේ), පසුව මුල් පන්තියට කෙසේ දැයි පරීක්ෂා කිරීම සඳහා සහායක පන්තියේ ව්‍යාජ අනුවාදයක් මුල් පන්තියට එන්නත් කරන්න. සහායකයාගේ ව්‍යතිරේකයන්ට ප්‍රතිචාර දක්වයි. උපකාරක පන්තිය පරීක්ෂා නොකර මුල් පන්තිය පරීක්ෂා කිරීමට ඔබට අවශ්‍ය නම් මෙම ප්‍රවේශය ද ප්‍රයෝජනවත් වේ.

පුද්ගලික ක්‍රම අත්හදා බැලීම ඔබේ පන්තියේ වටපිටාව බිඳ දමයි, මන්ද ඔබ අභ්‍යන්තර ක්‍රියාත්මක කිරීම වෙනස් කරන සෑම අවස්ථාවකම ඔබ සේවාදායක කේතය බිඳ දමයි (මේ අවස්ථාවේ දී, පරීක්ෂණ).

එබැවින් පුද්ගලික ක්‍රම පරීක්ෂා නොකරන්න.

JUnit.org නිති අසන ප්‍රශ්න පිටුවෙන් පිළිතුර :

නමුත් ඔබට අවශ්‍ය නම් ...

ඔබ JDK 1.3 හෝ ඊට වැඩි භාවිතා කරන්නේ නම්, වරප්‍රසාදලාභී ඇක්සෙසර්ගේ සහාය ඇතිව ප්‍රවේශ පාලන යාන්ත්‍රණය යටපත් කිරීමට ඔබට පරාවර්තනය භාවිතා කළ හැකිය . එය භාවිතා කරන්නේ කෙසේද යන්න පිළිබඳ විස්තර සඳහා, මෙම ලිපිය කියවන්න .

ඔබ JDK 1.6 හෝ ඊට වැඩි භාවිතා කරන්නේ නම් සහ ඔබේ පරීක්ෂණ estTest සමඟ විවරණය කරන්නේ නම්, ඔබේ පරීක්ෂණ ක්‍රමවල පරාවර්තනය එන්නත් කිරීමට ඔබට Dp4j භාවිතා කළ හැකිය . එය භාවිතා කරන්නේ කෙසේද යන්න පිළිබඳ විස්තර සඳහා, මෙම පරීක්ෂණ පිටපත බලන්න .

ප්රාදේශීය සභා මම ප්රධාන දායකත්වය ඉන්නේ Dp4j ඇසීමට, මට ඔබට උදව් අවශ්ය නම්. :)

ඔබට කේතය වෙනස් කළ නොහැකි පැරණි යෙදුමක පුද්ගලික ක්‍රම පරීක්ෂා කිරීමට ඔබට අවශ්‍ය නම්, ජාවා සඳහා එක් විකල්පයක් වන්නේ jMockit , එය පන්තියට පෞද්ගලිකව සිටියදී පවා වස්තුවකට විහිළු නිර්මාණය කිරීමට ඉඩ සලසයි.

මම පෞද්ගලික ක්‍රම අත්හදා බැලීමට නැඹුරු වෙමි. පිස්සුවක් තිබේ. පුද්ගලිකව, මම විශ්වාස කරන්නේ ඔබ ප්‍රසිද්ධියේ නිරාවරණය කළ අතුරුමුහුණත් පමණක් පරීක්ෂා කළ යුතු බවයි (එයට ආරක්ෂිත සහ අභ්‍යන්තර ක්‍රම ඇතුළත් වේ).

ඔබ JUnit භාවිතා කරන්නේ නම්, ජුනිට්-ඇඩෝන දෙස බලන්න . ජාවා ආරක්ෂක ආකෘතිය නොසලකා හැර පෞද්ගලික ක්‍රම සහ ගුණාංග වෙත ප්‍රවේශ වීමේ හැකියාව එයට ඇත.

ඔබේ කේතය ටිකක් ප්‍රතිනිර්මාණය කිරීමට මම ඔබට යෝජනා කරමි. ඔබේ කේතය පරික්ෂා කිරීම සඳහා, පරාවර්තනය හෝ වෙනත් ආකාරයේ දේවල් භාවිතා කිරීම ගැන සිතීමට පටන් ගත් විට, ඔබේ කේතයේ යමක් වැරදී ඇත.

ඔබ විවිධ ආකාරයේ ගැටළු සඳහන් කළා. පුද්ගලික ක්ෂේත්‍ර වලින් පටන් ගනිමු. පෞද්ගලික ක්ෂේත්‍රයන් නම් මම නව ඉදිකිරීම්කරුවෙකු එකතු කර ඒ සඳහා ක්ෂේත්‍ර එන්නත් කරමි. මේ වෙනුවට:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

මම මෙය භාවිතා කර ඇත:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

සමහර උරුම කේත සමඟ වුවද මෙය ගැටළුවක් නොවනු ඇත. පැරණි කේතය හිස් ඉදිකිරීම්කරුවෙකු භාවිතා කරනු ඇති අතර, ඔබ මගෙන් ඇසුවොත්, ප්‍රතිනිර්මාණය කරන ලද කේතය වඩා පිරිසිදු ලෙස පෙනෙනු ඇති අතර පරාවර්තනයකින් තොරව පරීක්ෂණයේදී අවශ්‍ය අගයන් එන්නත් කිරීමට ඔබට හැකි වේ.

දැන් පෞද්ගලික ක්‍රම ගැන. මගේ පෞද්ගලික අත්දැකීම් අනුව, ඔබට පරීක්ෂා කිරීම සඳහා පුද්ගලික ක්‍රමවේදයක් ඇනීමට සිදු වූ විට, එම ක්‍රමයට එම පන්තියේ කිසිදු සම්බන්ධයක් නැත. පොදු රටාවක් නම්, එය අතුරු මුහුණතක් තුළ ඔතා තැබීමයි , වැනි Callableඔබ පසුව එම අතුරුමුහුණතෙහි ඉදිකිරීම්කරු තුළ ද ගමන් කරයි (එම බහු ඉදිකිරීම් උපක්‍රමය සමඟ):

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

බොහෝ දුරට මා ලියා ඇති සියල්ල පෙනෙන්නේ එය යැපුම් එන්නත් රටාවක් ලෙස ය. මගේ පෞද්ගලික අත්දැකීම් වලදී එය පරීක්‍ෂා කිරීමේදී සැබවින්ම ප්‍රයෝජනවත් වන අතර, මම සිතන්නේ මේ ආකාරයේ කේත පිරිසිදු වන අතර එය නඩත්තු කිරීමට පහසු වනු ඇත. කැදැලි පංති ගැන මමත් එසේ කියමි. කැදැලි පන්තියක බර තර්කනයක් තිබේ නම්, ඔබ එය පැකේජයක් පුද්ගලික පංතියක් ලෙස ගෙන එය අවශ්‍ය පන්තියකට එන්නත් කර තිබීම හොඳය.

උරුම කේතය ප්‍රතිනිර්මාණය කිරීමේදී හා නඩත්තු කිරීමේදී මා භාවිතා කළ තවත් මෝස්තර රටා කිහිපයක් තිබේ, නමුත් ඒ සියල්ල රඳා පවතින්නේ පරීක්ෂා කිරීමට ඔබේ කේතයේ අවස්ථා මත ය. පරාවර්තනය භාවිතා කිරීම බොහෝ දුරට ගැටළුවක් නොවේ, නමුත් ඔබ ව්‍යවසාය යෙදුමක් ඇති විට එය දැඩි ලෙස පරීක්‍ෂා කර ඇති අතර සෑම යෙදවීමක්ම මන්දගාමී වීමට පෙර පරීක්ෂණ ක්‍රියාත්මක වේ (එය කරදරයක් වන අතර මම ඒ වගේ දේවල් වලට කැමති නැත).

සෙටර් එන්නත් ද ඇත, නමුත් මම එය භාවිතා කිරීම නිර්දේශ නොකරමි. මම ඉදිකිරීම්කරුවෙකු සමඟ රැඳී සිටිමින් සෑම දෙයක්ම සැබවින්ම අවශ්‍ය වූ විට ආරම්භ කර, අවශ්‍ය පරායත්තතාවයන් එන්නත් කිරීමේ හැකියාව අතහැර දමමි.

පුද්ගලික ක්‍රමයක් යනු එකම පන්තිය තුළට ප්‍රවේශ වීම පමණි. එබැවින් ඕනෑම පරීක්ෂණ පන්තියකින් ඉලක්ක පන්තියක “පුද්ගලික” ක්‍රමයක් පරීක්ෂා කිරීමට ක්‍රමයක් නොමැත. මගක් නම්, ඔබට අතින් පරීක්ෂණ සිදු කළ හැකිය, නැතහොත් ඔබේ ක්‍රමය “පුද්ගලික” සිට “ආරක්ෂිත” දක්වා වෙනස් කළ හැකිය.

එවිට ආරක්ෂිත ක්‍රමයක් ප්‍රවේශ කළ හැක්කේ පන්තිය අර්ථ දක්වා ඇති එකම පැකේජයක් තුළ පමණි. එබැවින්, ඉලක්ක පන්තියක ආරක්‍ෂිත ක්‍රමයක් පරීක්ෂා කිරීම යනු ඔබගේ පරීක්ෂණ පන්තිය ඉලක්ක පන්තියට සමාන පැකේජයක් තුළ නිර්වචනය කළ යුතු බවයි.

ඉහත සියල්ල ඔබගේ අවශ්‍යතාවයට නොගැලපේ නම් , පුද්ගලික ක්‍රමයට ප්‍රවේශ වීමට පරාවර්තන ක්‍රමය භාවිතා කරන්න.

ඉහත බොහෝ අය යෝජනා කර ඇති පරිදි, හොඳ ක්‍රමයක් වන්නේ ඔබේ පොදු අතුරුමුහුණත් හරහා ඒවා පරීක්ෂා කිරීමයි.

ඔබ මෙය කරන්නේ නම්, ඔබේ පුද්ගලික ක්‍රම ඇත්ත වශයෙන්ම ඔබේ පරීක්ෂණ වලින් ක්‍රියාත්මක වේදැයි බැලීමට කේත ආවරණ මෙවලමක් (එමා වැනි) භාවිතා කිරීම හොඳ අදහසකි.

පුද්ගලික ක්ෂේත්‍ර පරීක්ෂා කිරීම සඳහා මගේ සාමාන්‍ය කාර්යය මෙන්න:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

උදාහරණයක් සඳහා කරුණාකර පහත බලන්න;

පහත ආනයන ප්‍රකාශය එකතු කළ යුතුය:

import org.powermock.reflect.Whitebox;

දැන් ඔබට පුද්ගලික ක්‍රමය, කැඳවිය යුතු ක්‍රමයේ නම සහ අතිරේක පරාමිතීන් ඇති වස්තුව කෙලින්ම සම්මත කළ හැකිය.

Whitebox.invokeMethod(obj, "privateMethod", "param1");

අද, මම ජාවා පුස්තකාලයක් තල්ලු කර පෞද්ගලික ක්‍රම සහ ක්ෂේත්‍ර පරීක්ෂා කිරීමට උදව් කළෙමි. එය ඇන්ඩ්‍රොයිඩ් මනසින් නිර්මාණය කර ඇති නමුත් එය ඕනෑම ජාවා ව්‍යාපෘතියක් සඳහා සැබවින්ම භාවිතා කළ හැකිය.

ඔබට පුද්ගලික ක්‍රම හෝ ක්ෂේත්‍ර හෝ ඉදිකිරීම්කරුවන් සමඟ යම් කේතයක් තිබේ නම්, ඔබට BoundBox භාවිතා කළ හැකිය . එය ඔබ සොයන දේම කරයි. ඇන්ඩ්‍රොයිඩ් ක්‍රියාකාරකමක පුද්ගලික ක්ෂේත්‍ර දෙකකට එය පරීක්ෂා කිරීම සඳහා ප්‍රවේශ වන පරීක්ෂණයකට උදාහරණයක් පහත දැක්වේ:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

පුද්ගලික / ආරක්ෂිත ක්ෂේත්‍ර, ක්‍රම සහ ඉදිකිරීම්කරුවන් පරීක්ෂා කිරීම BoundBox පහසු කරයි. ඔබට උරුමයෙන් සැඟවී ඇති දේවල් වෙත පවා පිවිසිය හැකිය. ඇත්ත වශයෙන්ම, BoundBox සංවෘත කිරීම බිඳ දමයි. එය පරාවර්තනය තුළින් ඔබට ඒ සියල්ලට ප්‍රවේශය ලබා දෙනු ඇත, නමුත් සියල්ල සම්පාදනය කරන වේලාවේදී පරීක්ෂා කරනු ලැබේ.

සමහර උරුම කේත පරීක්ෂා කිරීම සඳහා එය ඉතා සුදුසු ය. එය ප්රවේශමෙන් භාවිතා කරන්න. ;)

https://github.com/stephanenicolas/boundbox

පළමුව, මම මෙම ප්‍රශ්නය ඉවත දමමි: ඔබේ පුද්ගලික සාමාජිකයින්ට හුදකලා පරීක්ෂණ අවශ්‍ය වන්නේ ඇයි? පොදු මතුපිටින් බැහැරව පරීක්ෂණ අවශ්‍ය වන පරිදි එවැනි සංකීර්ණ හැසිරීම් සපයන ඒවා සංකීර්ණද? එය ඒකක පරීක්ෂාව මිස 'රේඛීය රේඛා' පරීක්ෂණය නොවේ. කුඩා දේවල් දහඩිය දමන්න එපා.

ඔවුන් එතරම් විශාල නම්, මෙම පෞද්ගලික සාමාජිකයන් එක් එක් සංකීර්ණ 'ඒකකය' තරම් විශාල නම් - එවැනි පෞද්ගලික සාමාජිකයන් මෙම පන්තියෙන් පිටතට ප්‍රතිනිර්මාණය කිරීම ගැන සලකා බලන්න.

නැවත ප්‍රතිනිර්මාණය කිරීම නුසුදුසු හෝ කළ නොහැකි නම්, ඒකක පරීක්ෂණයකට භාජනය වන විට මෙම පුද්ගලික සාමාජික ක්‍රියාකාරකම් / සාමාජික පන්ති සඳහා ප්‍රවේශය ප්‍රතිස්ථාපනය කිරීමට උපාය මාර්ග රටාව භාවිතා කළ හැකිද? ඒකක පරීක්ෂණය යටතේ, උපායමාර්ගය අමතර වලංගු භාවයක් ලබා දෙනු ඇත, නමුත් මුදා හැරීමේදී එය සරල ගමන් මඟකි.

මට මෑතකදී මෙම ගැටළුව ඇති වූ අතර, පික්ලොක් නමින් කුඩා මෙවලමක් ලිවීය, එය ජාවා පරාවර්තන API පැහැදිලිව භාවිතා කිරීමේ ගැටළු මඟහරවා ගත හැකිය, උදාහරණ දෙකක්:

ඇමතුම් ක්‍රම, උදා private void method(String s)- ජාවා පරාවර්තනය මගින්

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

ඇමතුම් ක්‍රම, උදා private void method(String s)- පික්ලොක් විසිනි

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

ක්ෂේත්‍ර සැකසීම, උදා private BigInteger amount;- ජාවා පරාවර්තනය මගින්

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

ක්ෂේත්‍ර සැකසීම, උදා private BigInteger amount;- පික්ලොක් විසිනි

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito මේ සඳහා නිපදවා ඇත. මේවන් යැපීම භාවිතා කරන්න

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

එවිට ඔබට කළ හැකිය

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);