اختبر برنامجك

هذا الموضوع مهم جدا وهو من الاسس التي قام عليها مبدأ البرمجة الفائقة extreme programming

المبدأ الساسي الذي يقوم عليه junit هو انك لا تختبر البرنامج يدويا وانما تقوم بكتبة كود ليقوم باختبار برنامجك اوتوماتيكيا

اساس التسمية junit هو مبدأ unit testining بمعنى انك تقسم برنامجك الى وحدات تقوم باختبار كل منها على حدة هذه الوحدة كلما كانت اصغر كلما كانت افضل

يمكن ان تكون الوحدة class ولكن اذا كانت method فهو افضل

ادى ظهور الـ junit الى امكانية تطبيق مبدأ test driven development او test first development وهي قائمة على ان تكتب الاختبار قبل الشروع في كتابة الكود نفسه وبذلك عندما تنتهي من الاختبار بنجاح تكون قد حققت الغرض من البرنامج وهو اسلوب مفيد جدا في البرمجة ولكنه يحتاج الى تصميم جيد حتى يمكن تطبيقه

http://agilesoftwaredevelopment.com/videos/test-driven-development-basic-tutorial

http://live.eclipse.org/node/262

ويوجد أكثر من نوع من الاختبارات

unit test : يهتم بالتأكد من ان الوظيفة المطلوبة من الـ unit تم تغطيتها

integration test : يتم التأكد فيها من ان الانظمة المركبة من عدة مكونات تعمل مع بعضها بشكل صحيح

كما يوجد داخل الاختبار نفسه نوعين حتى يكون الاختبار متكاملا

success test : وفيه يتم التأكد ان تدفق البرنامج الايجابي يعمل بشكل صحيح ويؤدي الوظيفة المطلوبة (مثلا حالة true في جملة if الشرطية )

failure test : يتم فيه التأكد من المنطق المعكوس والأخطاء وفيه يتم اصطناع حالات خطأ والتأكد من انها يتم الامساك بها ولا تسبب توقف البرنامج (مثلا اعطاء قيمة reference = null والتأكد من امساك NullPointerException )

ومن المفيد في هذا السياق الحديث عن coverage tools ووظيفتها التأكد من أن كود الاختبار الذي كتبتها يغطي اكبر قدر ممكن من البرنامج وذلك مفيد جدا حيث ان الجزء الغير مغطى بالاختبار يمكن ان يكون معيبا وبه اخطاء تسبب توقف البرنامج

ومن أمثالها http://cobertura.sourceforge.net/

http://www.atlassian.com/software/clover

ارجو ان تكون هذه المقدمة مفيدة

اهاااااااااا , الموضوع مهم, يبدو ان الأخت Junit (والتي اعرفها بالإسم فقط) مكتوب لنا ان نفهمها في النهاية (إن شاء الله طبعا) على ايدكم يا اخوان :)

مبرووووك :cool: لكن لا افقه شيء فيها :wub:

Amgad hanafy كتب:

http://agilesoftware...-basic-tutorial

http://live.eclipse.org/node/262

هذه الروابط تحتوي على شرح مبسط بالفيديو ارجو ان تشاهدوها

اطلعت على المحاضرة وعلى الفيديو الذين وضعهم الأخ أمجد

بأمانة يستحق كل شكر عليهم

ولو أني لم أقتنع أنه سيعطي نتائج جيدة لكن ربما لو جربت اختلف الموضوع

على كل في خضم بحثي عن الموضوع وجدت مقالة يمكن البداية منها

http://www.vogella.de/articles/JUnit/article.html

بالطبع لي عودة إن شاء الله بعد أن أجرب

تحياتي

الإختبار(Testing) أنواع, من بينها و أهم ما يخص المطور هو إختبار الوحدات (Unit Testing).

أشهر حزم الإختبار هي xUnit فتجد cUnti, JUnit, NUnit, ..............

في الأساس, أي وحده (داله أو فئه )يقوم المبرمج بكتابتها يجب عليه أن يختبرها جيدا (و هذا هو ال unit testing , أي إختبار الوحدات)

و ال JUnit هو حزمه تسهل عليه هذه العمليه, لا أكثر ولا أقل, أي أنك ممكن أن تقوم بال Unit testing يدويا بدون أي حزم مساعده.

http://en.wikipedia.org/wiki/Unit_testing

أخ هويدي كلامك منطقي

على العموم أنا أفضل استخدام JUnit لأنها تسرع العملية

بالمناسبة لا أعتقد أن هناك مبرمج لا يقوم بفحص كوده

لكن المشكلة تكمن في كتابة شيفرة تفحص الشيفرة الكثير منا يجد الأمر متعب

بمعنى آخر أنا أجرب TestCase مباشرة على شيفرتي لكني لا أقوم بكتابة شيفرة وأحفظها عندي على أساس أنها عملية فحص

على كل في البداية كنت أعتقد أن الموضوع صعب أو على الأقل يحتاج بعض البحث

لكن فعلياً يبدو الموضوع أبسط مما كنت أعتقد

تحياتي

اقتباس

على العموم أنا أفضل استخدام JUnit لأنها تسرع العملية

أنا أري إن أهم ميزه في ال Unit Testing frameworks هي عمليه توثيق, فمثلا هب إن لدي الفئة التاليه :

package org.daz.perl;

/**
 * Represents a merchant/currency combination object
 * @author mhewedy
 */
public class MerchantCurrency {
	private String merchant;
	private String currency;

	public MerchantCurrency(String merchant, String currency) {
		validate(merchant, currency);
		this.merchant = merchant.trim();
		this.currency = currency.trim();
	}
	public String getCurrency() {
		return currency;
	}
	public String getMerchant() {
		return merchant;
	}
	private void validate(String merchant, String currency) {
		if (merchant == null || merchant.trim().length() == 0)
			throw new RuntimeException("Invalid merchant value :" + merchant);
		if (currency == null || currency.trim().length() != 3)
			throw new RuntimeException("Invalid currency value :" + merchant);
	}

	public boolean equals(Object obj) {
		if (obj == this) return true;
		if (!(obj instanceof MerchantCurrency)) return false;
		MerchantCurrency other = (MerchantCurrency) obj;
		if (this.merchant.equalsIgnoreCase(other.merchant) && 
				this.currency.equalsIgnoreCase(other.currency)) return true;
		return false;
	}
	public int hashCode() {
		int result = 17;
		result *= 31 + merchant.hashCode();
		result *= 31 + currency.hashCode(); 
		return result;
	}

	public String toString() {
		return "MerchantCurrency [ merchant : " + merchant + ", currency : " + currency + " ]"; 
	}
}

أهم شئ يمكن أن تختبره في هذه الفئة هما الدالتين equals & hashcode

بالنسبه للداله equals , من الممكن إن لم تكن تهتم بالتوثيق و تريد حاجه ع الماشي (ad-hoc solution) , يمكن أن تكتب main method تقوم بالإختبار.

مثل :

public static void main(String[] args) {
		MerchantCurrency mc = new MerchantCurrency("abc", "efg");
		System.out.println(mc.equals(new MerchantCurrency("abC", "efg")));

		System.out.println(mc.equals(new MerchantCurrency("abC", "efgc")));
//....................
	}

بالمناسبه, من أحلي الكتب في ال testing و في ال JUnit, هو JUnit in action

فعلاً هذه النقطة فاتتني

على الأقل عملية التوثيق تضمن لي ما هي الحالات التي تم فحصها فلا أعيد الفحص كل مرة أجد مشكلة

وإنما أبحث عن حالات أخرى

جاري محاولة الحصول على نسخة من الكتابة

(أحب أن أنوه إلى أنه ممنوع تبادل الكتب الغير قانونية)

تحياتي

اقتباس

(أحب أن أنوه إلى أنه ممنوع تبادل الكتب الغير قانونية)

+1

ال TDD او Test Driven Development هى عملية فحص الوحدات البرمجية قبل كتابتها بواسطة المطور و بعد استلامها من ال System Designers

هدف ال TDD هو التأكد من خلو التصميم من اى اخطاء قبل كتابة الكود و ايضاً لتوثيق النظام جيداً

قرأت من قبل في إحدي الكتب, أيضا أن ال Test Driven Development يتم فيها كتابة ال Test Cases و من ثم يتم كتابة ال Code الذي يحقق ال Test Cases

بالضبط ..... اعتماداً على Case Suite و Scenarios محددة من قبل

الميزة الاكبر هى استخدام ال CI Tests اوContinuous Integration Tests عند دمج اكثر من موديول او وحدة فنقوم بتشغيل هذه الاختبرات لاختبار كسر اى Logic سابق

طارق فم أستطع فهم آخر رد

هلا وضح الموضوع بشكل أكبر

تحياتي

الف شكر لجميع المشاركين فى هذا الموضوع

جزاكم الله كل خير

على الرغم من صعوبة فهم العنوان بالنسبة لى

لكن الحمد لله ...نوعا ما افهم عن اى شىء تتحدثون

دعنا نفترض ان لدى فئة خاصة للعملاء و ترتبط ب Business Rule يتأكد ان اقل عملية سحب بضاعة للعميل لا تتعدى ال 1000 دولار

و لديك فئة اخرى تمثل البضاعة

من قبل انت كان لديك Test Unit تتحقق من هذه الفئة و من ال Business Rule

جاء مديرك و طلب منك اجراء تعديلات على فئة العميل و قمت انت باجراء هذه التعديلات و طلب منى ان اقوم بعملية دمج تعديلاتك مع تعديلات اخرى تمت على الفئة التى تمثل البضاعة بواسطة مبرمج اخر

لكى اتأكد من ان عملية الدمج ستتم بصورة سليمة بدون كسر لل Business Rules فسأقوم بتنفيذ سلسلة من الاختبارات التى نسميها CI للتأكد من تحقيق ال Business Rule و عدم كسرها