ما هو أفضل إطار عمل وهمي لجافا؟[مغلق]

Question

ما هو أفضل إطار لإنشاء كائنات وهمية في Java؟لماذا؟ما هي إيجابيات وسلبيات كل إطار؟

Answer 1

لقد حققت نجاحًا جيدًا باستخدام موكيتو.

عندما حاولت التعلم عن JMock وEasyMock، وجدت أن منحنى التعلم شديد الانحدار (على الرغم من أنه ربما هذا أنا فقط).

أنا أحب Mockito بسبب تركيبه البسيط والواضح الذي تمكنت من فهمه بسرعة كبيرة.تم تصميم الحد الأدنى من بناء الجملة لدعم الحالات الشائعة بشكل جيد للغاية، على الرغم من أنني في المرات القليلة التي كنت أحتاج فيها إلى القيام بشيء أكثر تعقيدًا وجدت أن ما أريده كان مدعومًا وسهل الفهم.

إليك مثال (مختصر) من صفحة Mockito الرئيسية:

import static org.mockito.Mockito.*;

List mockedList = mock(List.class);
mockedList.clear();
verify(mockedList).clear();

لا يصبح الأمر أبسط من ذلك بكثير.

الجانب السلبي الرئيسي الوحيد الذي يمكنني التفكير فيه هو أنه لن يسخر من الأساليب الثابتة.

Answer 2

أنا منشئ PowerMock لذا من الواضح أنني يجب أن أوصي بذلك!:-)

باور موك يمتد كلاً من EasyMock وMockito مع القدرة على ذلك أساليب ثابتة وهمية, والطرق النهائية وحتى الخاصة.اكتمل دعم EasyMock، لكن المكون الإضافي Mockito يحتاج إلى المزيد من العمل.نحن نخطط لإضافة دعم JMock أيضًا.

ليس المقصود من PowerMock أن يحل محل أطر العمل الأخرى، بل يمكن استخدامه في المواقف الصعبة عندما لا تسمح الأطر الأخرى بالسخرية.يحتوي PowerMock أيضًا على ميزات مفيدة أخرى مثل قمع المُهيئات الثابتة والبنائين.

Answer 3

ال موقع مشروع JMockit يحتوي على الكثير من المعلومات المقارنة لمجموعات أدوات السخرية الحالية.

على وجه الخصوص، تحقق من مصفوفة مقارنة الميزات, ، والذي يغطي EasyMock، وjMock، وMockito، وUnitils Mock، وPowerMock، وبالطبع JMockit.أحاول أن أبقيها دقيقة وحديثة قدر الإمكان.

Answer 4

لقد حققت النجاح مع JMockit.

إنها جديدة تمامًا، وبالتالي فهي خام بعض الشيء وغير موثقة.يستخدم أسم لإعادة تعريف الرمز الثانوي للفئة ديناميكيًا، حتى يتمكن من الاستهزاء بجميع الأساليب بما في ذلك الطرق الثابتة والخاصة والمنشئات والمهيئات الثابتة.على سبيل المثال:

import mockit.Mockit;

...
Mockit.redefineMethods(MyClassWithStaticInit.class,
                       MyReplacementClass.class);
...
class MyReplacementClass {
  public void $init() {...} // replace default constructor
  public static void $clinit{...} // replace static initializer
  public static void myStatic{...} // replace static method
  // etc...
}

يحتوي على واجهة توقعات تسمح بسيناريوهات التسجيل/التشغيل أيضًا:

import mockit.Expectations;
import org.testng.annotations.Test;

public class ExpecationsTest {
  private MyClass obj;

  @Test
  public void testFoo() {
    new Expectations(true) {
      MyClass c;
      {
        obj = c;
        invokeReturning(c.getFoo("foo", false), "bas");
      }
    };

    assert "bas".equals(obj.getFoo("foo", false));

    Expectations.assertSatisfied();
  }

  public static class MyClass {
    public String getFoo(String str, boolean bool) {
      if (bool) {
        return "foo";
      } else {
        return "bar";
      }
    }
  }
}

الجانب السلبي هو أنه يتطلب Java 5/6.

Answer 5

يمكنك أيضًا إلقاء نظرة على الاختبار باستخدام Groovy.في Groovy، يمكنك بسهولة محاكاة واجهات Java باستخدام عامل التشغيل "as":

def request = [isUserInRole: { roleName -> roleName == "testRole"}] as HttpServletRequest 

بصرف النظر عن هذه الوظيفة الأساسية، يقدم Groovy الكثير على الجانب الساخر، بما في ذلك الأداء القوي MockFor و StubFor الطبقات.

http://docs.codehaus.org/display/GROOVY/Groovy+Mocks

Answer 6

لقد بدأت باستخدام يسخر مع ايزي موك.من السهل أن نفهم، ولكن خطوة إعادة التشغيل كانت مزعجة نوعا ما. موكيتو يزيل هذا، ويحتوي أيضًا على بناء جملة أكثر نظافة حيث يبدو أن سهولة القراءة كانت أحد أهدافه الأساسية.لا أستطيع التأكيد بما فيه الكفاية على مدى أهمية ذلك، حيث أن معظم المطورين سيقضون وقتهم في قراءة التعليمات البرمجية الموجودة والحفاظ عليها، وليس إنشائها.

شيء جميل آخر هو أنه يتم التعامل مع الواجهات وفئات التنفيذ بنفس الطريقة، على عكس EasyMock حيث لا تزال بحاجة إلى التذكر (والتحقق) لاستخدام ملحق EasyMock Class Extension.

لقد ألقيت نظرة سريعة على JMockit مؤخرًا، وعلى الرغم من أن قائمة ميزات الغسيل شاملة جدًا، أعتقد أن ثمن ذلك هو وضوح الكود الناتج، والاضطرار إلى كتابة المزيد.

بالنسبة لي، Mockito هو الأفضل، حيث أنه سهل الكتابة والقراءة، ويتعامل مع غالبية المواقف التي تتطلبها معظم التعليمات البرمجية.استخدام موكيتو مع باور موك سيكون خياري.

أحد الأشياء التي يجب أخذها في الاعتبار هو أن الأداة التي ستختارها إذا كنت تقوم بالتطوير بنفسك، أو في فريق صغير متماسك، قد لا تكون الأفضل لشركة كبيرة بها مطورين بمستويات مهارات مختلفة.ستحتاج سهولة القراءة وسهولة الاستخدام والبساطة إلى مزيد من الاهتمام في الحالة الأخيرة.لا معنى للحصول على إطار عمل ساخر نهائي إذا انتهى الأمر بالكثير من الأشخاص إلى عدم استخدامه أو عدم الحفاظ على الاختبارات.

Answer 7

نحن نستخدم بكثرة ايزي موك و EasyMock Class Extension في العمل وهم سعداء جدًا به.إنه يمنحك بشكل أساسي كل ما تحتاجه.قم بإلقاء نظرة على الوثائق، هناك مثال رائع يوضح لك جميع ميزات EasyMock.

Answer 8

لقد استخدمت JMock في وقت مبكر.لقد قمت بتجربة Mockito في مشروعي الأخير وأعجبني.أكثر إيجازا وأكثر نظافة.يغطي PowerMock جميع الاحتياجات التي لا توجد في Mockito، مثل السخرية من التعليمات البرمجية الثابتة، والسخرية من إنشاء المثيل، والسخرية من الفئات والأساليب النهائية.لذلك لدي كل ما أحتاجه لأداء عملي.

Answer 9

أنا أحب JMock لأنك قادر على تحديد التوقعات.وهذا يختلف تمامًا عن التحقق من وجود طريقة ما في بعض المكتبات الوهمية.باستخدام JMock يمكنك كتابة توقعات معقدة للغاية.شاهد الجموك الغش.

Answer 10

نعم، Mockito هو إطار عظيم.أنا استخدامها جنبا إلى جنب مع هامكريست و جوجل جيس لإعداد اختباراتي.

Answer 11

أفضل حل للسخرية هو جعل الآلة تقوم بكل العمل من خلال اختبار آلي قائم على المواصفات.بالنسبة لجافا، راجع سكالاشيك و ال اختزال الإطار المتضمن في جافا الوظيفية مكتبة.باستخدام أطر الاختبار الآلية القائمة على المواصفات، يمكنك توفير مواصفات الطريقة قيد الاختبار (خاصية عنها يجب أن تكون صحيحة) ويقوم الإطار بإنشاء اختبارات بالإضافة إلى كائنات وهمية تلقائيًا.

على سبيل المثال، تقوم الخاصية التالية باختبار الأسلوب Math.sqrt لمعرفة ما إذا كان الجذر التربيعي لأي رقم موجب n تربيع يساوي n.

val propSqrt = forAll { (n: Int) => (n >= 0) ==> scala.Math.sqrt(n*n) == n }

عندما تتصل propSqrt.check(), ، يقوم ScalaCheck بإنشاء مئات الأعداد الصحيحة ويتحقق من الممتلكات الخاصة بك لكل منها، كما يتأكد تلقائيًا من تغطية حالات الحافة جيدًا.

على الرغم من أن ScalaCheck مكتوب بلغة Scala، ويتطلب مترجم Scala، فمن السهل اختبار تعليمات Java البرمجية باستخدامه.يعد إطار عمل Reductio في Java الوظيفية تطبيق Java خالصًا لنفس المفاهيم.

Answer 12

يوفر Mockito أيضًا خيار طرق الاستدعاء، ومطابقة الوسائط (مثل AnyInt() وanyString())، والتحقق من عدد الاستدعاءات (مرات (3)، atLeastOnce()، أبدًا())، و اكثر.

لقد وجدت أيضًا أن Mockito كذلك بسيطة ونظيفة.

الشيء الوحيد الذي لا يعجبني في Mockito هو أنت لا يمكن إيقاف الأساليب الثابتة.

Answer 13

لشيء مختلف قليلا، يمكنك استخدام جي روبي و موكا التي يتم دمجها في JtestR لكتابة اختبارات لكود Java الخاص بك بلغة روبي معبرة وموجزة.هناك بعض الأمثلة الساخرة المفيدة مع JtestR هنا.إحدى مزايا هذا النهج هو أن السخرية من الطبقات الخرسانية أمر واضح ومباشر.

Answer 14

لقد بدأت باستخدام النماذج من خلال JMock، ولكنني انتقلت في النهاية إلى استخدام EasyMock.لقد كان EasyMock كذلك، --أسهل -- وقدم بناء جملة يبدو أكثر طبيعية.لم أتحول منذ ذلك الحين.