لماذا أكتب الاختبارات في النهاية، ولماذا هذا ليس ما تعتقد أنه يعني
**أخذ التدابير المتعارضة:**إن تطوير " Test-Driven Development " ممارسة رائعة تحل المشكلة الخاطئة لمعظم الأعمال الإبداعية.
المراحل الثلاث من برامجيات البناء (تلك الأعمال المنجزة)
هذه هي الطريقة التي أبني بها البرمجيات.
انها بسيطة، انها فعالة، وأنها تجعل من TD بوحومهم مهذبة بشكل مؤدب:
جعله يعمل.أجعله جميلاًاقفل عليه مع الاختبارات.
graph TB
Start[New Feature Request] --> P1[Phase 1: Make It Work]
P1 --> P1_Private[Private Exploration]
P1_Private --> P1_Sketch["Sketch the solution<br/>Messy code OK<br/>No tests yet<br/>Focus on learning"]
P1_Sketch --> P1_Run["Run it manually<br/>Try different inputs<br/>See what breaks<br/>Understand the problem"]
P1_Run --> P1_Decision{Does it work<br/>basically?}
P1_Decision -->|No| P1_Iterate[Try different approach]
P1_Iterate --> P1_Sketch
P1_Decision -->|Yes| P2
P2[Phase 2: Make It Pretty] --> P2_Refine[Private Refinement]
P2_Refine --> P2_Clean["Clean up the code<br/>Better names<br/>Type hints/annotations<br/>Clear structure"]
P2_Clean --> P2_Align["Align with spec<br/>Cover all requirements<br/>Handle edge cases<br/>Polish API surface"]
P2_Align --> P2_Optimise["Optimise<br/>Performance<br/>Readability<br/>Maintainability"]
P2_Optimise --> P3
P3[Phase 3: Lock It Down] --> P3_Share[Public Sharing]
P3_Share --> P3_Tests["Write comprehensive tests<br/>Full coverage<br/>Edge cases<br/>Error conditions"]
P3_Tests --> P3_CI["CI/CD Integration<br/>Automated testing<br/>Code review<br/>Documentation"]
P3_CI --> P3_Deploy["Ready to Share<br/>Commit to main<br/>Deploy to prod<br/>Other devs can use it"]
P3_Deploy --> Done[Well-Tested,<br/>Well-Designed Code]
style P1 stroke:#ff6b6b,stroke-width:3px
style P2 stroke:#4ecdc4,stroke-width:3px
style P3 stroke:#95e1d3,stroke-width:3px
style Done stroke:#38ada9,stroke-width:4px
في هذا الترتيب.*دائماً دائماً.*ليس لأنني كسول.
ليس لأنني لا أُقيّم الإختبارات.
هكذا يحدث العمل الإبداعي في الواقع
عندما تستكشف مساحة مشكلة لا تفهمها تماماً بعد
عندما تستكشف مساحة مشكلة لا تفهمها تماماً بعد
اسمحوا لي أن أشرح.
هذا هو الجزء الفوضوي.الجزء حيث ليس لدي أي فكرة عما أفعله
أنا أحاول أن أفهم:
هل هذا API في الواقع يعمل بالطريقة التي يطالب بها الأطباء؟
هل يمكنني حل هذه المشكلة بالأدوات التي لدي؟
ماذا تعني كلمة "صحيحة" حتى في هذا السياق؟*هل هذه مشكلة لساعتين أم مشكلة لأسبوعين؟*هذا هو الإختراع.
هذا هو الاستكشاف.
هذا هو الجاز.
# Ugly, exploratory code
def process_thing(data):
# TODO: This is terrible, fix later
result = []
for item in data:
# Not sure if this is the right approach...
x = item.get('value')
if x: # Is this even the right condition?
result.append(x * 2) # Why multiply by 2? Testing something...
return result
وأنت تعرف ماذا يَقْتلُ الجازَ؟**شخص يقف فوق كتفك يقول "أكتب الاختبار أولاً"**لماذا لا توجد اختبارات بعد؟
(السبب)*لا يزال شكلها ماثلاً.*تخيل أنك ناصور.
لديك كتلة من الرخام وفكرة مبهمة: "أريد أن أنحت طائراً."
عرّف أجنحته.حدّد زاوية من.
والآن ننقر إلى تلك المواصفات."*هذه ليست الطريقة التي تنحت بها الطيور. (أو يتم كتابة البرمجيات، كما يتضح).*الناشرات الحقيقية
من خلال الشكل الأول.إنهم يرسمون رسماً.
إنهم يصنعون ماكينات.*انهم يرققون بعيدا قطع كبيرة من الحجر للعثور على الشكل العام.*وفي وقت لاحق فقط يقومون بصقل التفاصيل.
الشفرة هي نفسها.
هذا الشفرة هو
مـن القطاع الخاص مـن القطاع الخاص
إنها محادثة مع نفسي
هكذا أكتشف معنى "العمل" حتى
2 - على نحو فعال.
لأنه في كل مرة أدرك "أوه انتظر، هذا النهج كله هو خطأ،" يجب أن أعيد كتابة الاختبارات أيضا.
هذا ليس محجّراً.
حرية الفشل السريع
# Before (Phase 1) - Exploratory code
def process_thing(data):
result = []
for item in data:
x = item.get('value')
if x:
result.append(x * 2)
return result
# After (Phase 2) - Refined code
def extract_doubled_values(items: list[dict]) -> list[int]:
"""Extract 'value' field from items and double each one.
Only includes items where 'value' is present and truthy.
"""
return [
item['value'] * 2
for item in items
if item.get('value')
]
المرحلة الأولى هي حوالي
// Before (Phase 1) - Exploratory code
public List<int> ProcessThing(List<Dictionary<string, object>> data)
{
var result = new List<int>();
foreach (var item in data)
{
if (item.ContainsKey("value"))
{
var x = item["value"];
if (x != null)
{
result.Add(Convert.ToInt32(x) * 2);
}
}
}
return result;
}
// After (Phase 2) - Refined code
/// <summary>
/// Extracts 'value' field from items and doubles each one.
/// Only includes items where 'value' is present and non-null.
/// </summary>
public IEnumerable<int> ExtractDoubledValues(IEnumerable<IDictionary<string, object>> items)
{
return items
.Where(item => item.ContainsKey("value") && item["value"] != null)
.Select(item => Convert.ToInt32(item["value"]) * 2);
}
(أ) سرعة التعلم.
أريد أن أكتشف أن مكتبة الطرف الثالث التي ظننت أنني سأستخدمها... ليست كما أعلن عنها تماماً.أريد أن أدرك أن المشكلة التي أحلها ليست المشكلةينبغي أن يكون*حلّ.*الاختبارات تبطئ هذا إلى أسفل.
ليس لأن الاختبار بطيء لكن لأن
ثمّ أَنا عاطفياً إستثمرتُ في الشيءِ الخاطئِ.
من الأفضل أن تفشل بسرعة، على إنفراد، مع عدم وجود إختبارات للحفاظ عليها وبدون غرور للحماية.ما هي وسائل "العمل" في المرحلة 1إنها تعني: "لقد قمت بتشغيلها.
أعطيتُه بَعْض المدخلاتِ.
# Phase 1: Works, but awkward to use
process_thing(data)
# Phase 2: Clear, flexible, composable
extract_doubled_values(
items,
scale_factor=2.0,
include_zeros=False
)
ونتجت عنها نواتج تبدو معقولة.
// Phase 1: Works, but awkward to use
ProcessThing(data);
// Phase 2: Clear, flexible, composable
ExtractDoubledValues(
items,
scaleFactor: 2.0,
includeZeros: false
);
// Or even better with a fluent API
items.ExtractValues()
.Scale(by: 2.0)
.ExcludingZeros()
.ToList();
أنا واثق من أنني أفهم المشكلة الآن."
هذا هو عليه.**لا توجد حالات تجاوزات.**لا يوجد خطأ في المناولة.
graph LR
subgraph "Phase 2 Refinement Process"
A[Rough Code] --> B[Clean Structure]
B --> C[Add Types]
C --> D[Polish API]
D --> E[Static Analysis]
E --> F{Quality Gates Pass?}
F -->|No| G[Fix Issues]
G --> B
F -->|Yes| H[Ready for Phase 3]
end
style A stroke:#ff6b6b,stroke-width:3px
style H stroke:#95e1d3,stroke-width:3px
*فقط a فقط a أعلى.*إثبات للمفهوم.
رسم تخطيطي.المرحلة 2: جعله أمراً جميلاً (المعاملة)
حسناً، الآن أفهم المشكلةلدي شيء يعمل، على الأقل للمسار السعيد.
الآن يمكنني البدء بالإهتمام بالنوعية.
مثال Python:**اسم أفضل للاسم.
الشروح من نوع الشروح.*وثائق XML.*تنفيذ الخطة المتوسطة الأجل.
مُحاط مع المسند
الآن وأنا أعرف ما أنا في الواقع بناء، أعود إلى المتطلبات الأصلية وأتأكد من أنني حل
الحق في حق
وهذا يكشف في كثير من الأحيان عن وجود ثغرات:
"أوه، أرادوا هذا للتعامل مع الأعداد السالبة بشكل مختلف."
الخبرة المكتسبة في هذا المجال.بايثون:& & #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
تحسين التسمية.
لماذا لا توجد اختبارات؟
def test_extract_doubled_values_basic():
items = [{'value': 5}, {'value': 10}]
assert extract_doubled_values(items) == [10, 20]
def test_extract_doubled_values_skips_missing_values():
items = [{'value': 5}, {'name': 'foo'}, {'value': 3}]
assert extract_doubled_values(items) == [10, 6]
def test_extract_doubled_values_handles_zeros():
items = [{'value': 0}, {'value': 5}]
# By default, zeros are excluded (falsy)
assert extract_doubled_values(items) == [10]
def test_extract_doubled_values_includes_zeros_when_configured():
items = [{'value': 0}, {'value': 5}]
assert extract_doubled_values(items, include_zeros=True) == [0, 10]
def test_extract_doubled_values_custom_scale_factor():
items = [{'value': 5}]
assert extract_doubled_values(items, scale_factor=3.0) == [15.0]
def test_extract_doubled_values_rejects_negative_scale_factor():
with pytest.raises(ValueError):
extract_doubled_values([], scale_factor=-1.0)
def test_extract_doubled_values_handles_empty_list():
assert extract_doubled_values([]) == []
def test_extract_doubled_values_handles_non_numeric_values():
items = [{'value': 'not a number'}]
with pytest.raises(TypeError):
extract_doubled_values(items)
أنا أديره بإستمرار
لدي فتحة مفتوحة.
(السبب)
# This comment will drift from reality:
# Doubles all numeric values, skipping None
# This test will fail if reality changes:
def test_extract_doubled_values_skips_none_values():
items = [{'value': None}, {'value': 5}]
assert extract_doubled_values(items) == [10]
ما زلت أكتشف ما يستحق الاختبار
في المرحلة 1، لم أكن أعرف ما إذا كانت هذه الدالة حتى موجودة.في المرحلة الثانية، أنا أستكشف:"أوه، عامل المقياس لا يمكن أن يكون سالب.
"إذا كانت القائمة فارغة، يجب أن نعود فارغة، وليس لا شيء.""نحن بحاجة للتعامل مع القيم غير العددية برشاقة."
أولاً - معلومات أساسية
من إعادة التصنيع.
إنهم ليسوا واضحين في المقدمة.
الشفرة نظيفة.*الـ API منطقي.*لقد غطّيت الحالات العارضة.
الآن أنا أكتب الإختبارات.
الكثير من الاختبارات
كإختبارات محتملةلماذا الآن؟
(السبب)
"الاختبارات هي آلية مشاركة."إنهم ليسوا لي بعد الآن
أنا بالفعل أفهم هذا القانون بشكل وثيق.
الـ مُنْطِل
(التي تحتاج إلى منع الانحدارات)
حافظات المستقبل
الاختبارات هي:عرض لطبقة العرض
من أجل تنفيذي.الوثائق:
ما تفعله هذه الشفرةما إذا كان المدخلات صحيحةالنواتج المتوقعة
ما هي الافتراضات التي أقوم بها
التغطية الكاملة، بدون حل وسط
غيّر هذه الدالة طمأني
كوثائق
3 - الوثائق القابلة للتنفيذ.
graph TB
subgraph "Traditional TDD (Red-Green-Refactor)"
TDD1[Write Failing Test] --> TDD2[Write Minimal Code to Pass]
TDD2 --> TDD3[Refactor]
TDD3 --> TDD1
end
subgraph "Three-Phase Approach (Explore-Refine-Lock)"
P1[Explore Solution Space] --> P2[Refine Implementation]
P2 --> P3[Write Comprehensive Tests]
P3 --> P4[Share With Team]
end
style TDD1 stroke:#ffaa00,stroke-width:2px
style TDD2 stroke:#ffaa00,stroke-width:2px
style TDD3 stroke:#ffaa00,stroke-width:2px
style P1 stroke:#ff6b6b,stroke-width:3px
style P2 stroke:#4ecdc4,stroke-width:3px
style P3 stroke:#95e1d3,stroke-width:3px
**لكنني أيضاً لا أكتب اختبارات قبل أن تكون الشفرة جاهزة للمشاركة.**وفيما يلي المراحل:
الاستكشاف(فقط لي، لا اختبارات)
من القطاع الخاص
(فقط أنا، لا تزال لا توجد اختبارات) |-----|-------------|
(الاختبارات، CI، مراجعة رمزية، كامل 9 ياردة) هذا يحمي كلا من إبداعيوقد عقد مؤتمراً بشأن | صحة فريقي من أعضاء فريقي. لِمَ يَحْمِلُ هٰذَا ؟
حقًّا!ولكن فقط إذا كنت تعرف بالفعل ما أنت بناء.
عندما أَنا في المرحلةِ 1، أنا لَستُ بِحاجةٍ إلى الثقةِ للمُؤَمِّنِ.
Hour 1: Write test for API I haven't designed yet
Hour 2: Realize the API is wrong, rewrite test
Hour 3: Discover a better approach, rewrite both
Hour 4: Finally get it working
Hour 5: Rewrite tests to match what actually works
أحتاج تصريحاً لأرمي كل شيء بعيداً
Hour 1: Explore 3 different APIs, settle on the best one
Hour 2: Refine the implementation, handle edge cases
Hour 3: Write comprehensive tests for what I built
Hour 4: All tests pass, commit with confidence
الاختبارات تخلق الديون النفسية.
حتى لو كانوا يختبرون الشيء الخطأعن طريق تأجيل الاختبارات حتى المرحلة 3، أبقي على المرحلتين 1 و2
رخيصة نفسياً
ويمكنني:
اكشف عن المشكلة التي اناحاصلاًأولاً - مقدمة
هذه هي الطريقة التي يعمل بها الإبداع.
// Test 1: Write test first (but I don't know the right API yet)
[Test]
public void TestProcessData()
{
var processor = new DataProcessor();
var result = processor.Process(new[] { 1, 2, 3 });
Assert.That(result, Is.EqualTo(new[] { 2, 4, 6 }));
}
// Implementation 1: Make it pass
public class DataProcessor
{
public int[] Process(int[] data) => data.Select(x => x * 2).ToArray();
}
// Later: Realize I need configurability, rewrite test
[Test]
public void TestProcessDataWithFactor()
{
var processor = new DataProcessor();
var result = processor.Process(new[] { 1, 2, 3 }, factor: 3);
Assert.That(result, Is.EqualTo(new[] { 3, 6, 9 }));
}
// Later: Realize I should use IEnumerable, rewrite test again
[Test]
public void TestProcessDataEnumerable()
{
var processor = new DataProcessor();
var data = GetLargeDataset(); // This should be lazy
var result = processor.Process(data, factor: 3);
Assert.That(result.Take(3), Is.EqualTo(new[] { 3, 6, 9 }));
}
تُخطّطُ أولاً.
أنت لا تبدأ مع التفاصيل.
// Phase 1: Explore (no tests yet)
public int[] ProcessThing(int[] data)
{
return data.Select(x => x * 2).ToArray();
}
// Try it: var result = ProcessThing(new[] { 1, 2, 3 });
// Hmm, what about configurability? What about lazy evaluation?
// Phase 2: Refine (still no tests)
public static class DataProcessorExtensions
{
public static IEnumerable<int> Scale(
this IEnumerable<int> source,
int factor = 2)
{
return source.Select(x => x * factor);
}
}
// Try it: var result = data.Scale(factor: 3).ToList();
// Much better API!
// Phase 3: Lock it down (NOW write tests, correctly)
[TestFixture]
public class DataProcessorTests
{
[Test]
public void Scale_DefaultFactor_DoublesValues()
{
var result = new[] { 1, 2, 3 }.Scale();
Assert.That(result, Is.EqualTo(new[] { 2, 4, 6 }));
}
[Test]
public void Scale_CustomFactor_ScalesCorrectly()
{
var result = new[] { 1, 2, 3 }.Scale(factor: 3);
Assert.That(result, Is.EqualTo(new[] { 3, 6, 9 }));
}
[Test]
public void Scale_LazyEvaluation_DoesNotEnumerateImmediately()
{
var enumerated = false;
var data = GetTestData(() => enumerated = true);
var scaled = data.Scale(factor: 2);
Assert.That(enumerated, Is.False, "Should not enumerate yet");
scaled.ToList();
Assert.That(enumerated, Is.True, "Should enumerate on materialization");
}
[Test]
public void Scale_EmptySequence_ReturnsEmpty()
{
var result = Enumerable.Empty<int>().Scale();
Assert.That(result, Is.Empty);
}
}
كيف يتناسب هذا مع العامل والمعامل والعامل (وأين يفرق)
هذا ليس "تطوراً لاحقاً"
هذا
لإضافة اختبارات وحدة هو أمر حرج.
الممارسات التي أحفظها
كل سمة تمر من خلال CI قبل دمج
تحسين التصميمم بسيط
المرحلة الثانية هي:
تُخصص المرحلة 2 وقتاً لإعادة التشغيلكَشّف الشفرةثالثاً
**(في المرحلة 3++)**حيث أَغْفُرُ مِنْ مُقْتَرَضَ
يقول MTDD:"الخبرات الأولى.
دائماً دائماً.الأحمر-الخضر-المفاعل هو الطريقة الوحيدة."
أقول:"تجارب عندما تعرف ما الذي تختبره"
اكتشاف-Refine-Llock هو أكثر طبيعية."
ثالثا - المرحلة الثالثةيُعَرِّف الاختبار الواجهة □ يُعَرِّف الواجهة □
□ اختبر أولا لكل شيء □ اختبر في الوقت المناسب لكل شيء □
التوقيت الصحيح (المرحلة 3):
نفس نتيجة الجودة.*نِصْف المَضْعَةِ.*هذا مُعامل
"مرتقب أن يتغير أكثر من اتباع خطة."ويمكن أن يصبح مرض نقص المناعة المكتسب شكله الخاص به لمتابعة الخطة.
بمجرد أن تكتب الاختبارات، تكون ملتزماً نفسياً بذلك التصميم.
هذا*+ +*
نُهُج الموانع: A C# مثال
-ألاحظ المُؤخّر؟
ثلاثة إختبارات إعادة كتابة بينما التصميم تطوّر.
تَذَكّر القيم:
المرحلة الأولى من الوصول إلى برامجيات العمل
-لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا.
التعاون عندما يساعد (المرحلة 2-3-3)، يستكشف وحده عندما لا يساعد (المرحلة 1)
الدالة 2 متوائمة مع الوصف
ما بعد
السبب:
أنت لم تكن تعرف الحالات القصوى حتى الآنواكتشفت تصميما أفضل من تصميم APIأدركت أن الميزه لم تكن ضروريه على الإطلاق
كل اختبار تكتبه في المرحلة الأولى هو على الأرجح جهد مهدر.
واحد
مجموعة من الاختبارات في المرحلة 3، عندما تعرف في الواقع ما الذي تبنيه، من كتابة - إعادة كتابة - إعادة كتابة أثناء الاستكشاف.وعد TDD مقابل الواقعوعود TD TDD:
"Write code that solves the specification.
Don't worry about perfection yet.
Just get it working."
"التجارب تقود تصميمك!
الآن أنا أعيد كتابة كل من الاختبارات والشفرة."هذا ليس تصميماًهذا هو
مُتَدْوَمَةً.نهجي:
التصميم من خلال التنفيذ، ثم قفل عليه مع الاختبارات.
"لا اختبارات"*"الانسكاب والصلاة"*بحلول الوقت الذي أنتهي فيه من المرحلة الثالثة، شفرتي تقول:
التغطية بالاختبار الشاملعدد الحالات التي تم التعامل فيها
امسح التصميمالوثائق )الاختبارات البيانية(
تماماً مثل (تي دي دي)
الفرق هو
والقاعدة بسيطة:
- flake8 (style checking)
- pylint (code quality)
- mypy (type checking)
- black (formatting)
- radon (complexity analysis)
**لا يوجد رمز يترك المرحلة 2 بدون المرحلة 3.**أنا لا أفعل ما يلي:
for iteration in range(3):
# Measure current performance
metrics = measure_performance(code)
# Generate improved version
better_code = optimise(code, metrics)
# Keep if better, discard if worse
if better_code.score > code.score:
code = better_code
قيد غير مُختبرفتح المراسلات بدون اختباراتالانتقال إلى المركز الرئيسي دون المرور
هذه ليست فكرة جديدةهكذا كان العمل الإبداعي يعمل دائماً:
الطلاء لا يبدأ بالفرشاة النهائيةالجهات التالية:& هذاالتكوين (المرحلة الأولى)
سندSSSSS*(المرحلة الثانية)*
# Test generation happens AFTER optimisation
def generate_unit_tests(specification, optimized_code):
"""Generate comprehensive tests for refined code.
This happens in Phase 3, after we know:
- What the code actually does
- What edge cases exist
- What the API surface looks like
"""
return llm.generate(
f"""Generate comprehensive unit tests for this code.
Specification: {specification}
Implementation: {optimized_code}
Include tests for:
- Happy path (from spec examples)
- Edge cases (discovered during optimisation)
- Error conditions (based on actual error handling)
- Performance bounds (based on measured metrics)
"""
)
(المرحلة 3)
الجهات التالية:مشروع(المرحلة 1)
**(المرحلة 3)**والجليد حاسم الأهمية.
كيف هذه الخرائط لـ منفذهنا حيث يصبح هذا مثيراً للاهتمام: أنا في الواقع(بآلاف دولارات الولايات المتحدة)
هذه الفلسفة في نظام DISE (التطور الاصطناعي المحدد).
لا يوجد سابق سابق لأوانهاً
حاول مرة أخرى مع أعلى الإبداع (درجة حرارة أعلى)
User: "Calculate fibonacci numbers"
[Phase 1: Exploration - 3 attempts]
Attempt 1: Works for small inputs, explodes on large ones (no safety limit)
Attempt 2: Adds safety limit, but inefficient recursive approach
Attempt 3: Switches to iterative DP (PASS)
[Phase 2: Optimization - 3 iterations]
Iteration 1: Add type hints, improve naming (Score: 1.05)
Iteration 2: Optimize memory usage with generator (Score: 1.10)
Iteration 3: Add input validation (Score: 1.15)
[Phase 3: Testing and Storage]
Generated 8 unit tests covering:
- Basic cases (n=0, n=1, n=5, n=10)
- Edge cases (n=negative, n=100, n=None)
- Type validation
All tests pass ✓
Stored in RAG with quality score: 1.15
Available for reuse: YES
إلى نموذج أكثر قوة
*لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا.*1 - المرحلة 1
ولا تُكتب أي اختبارات خلال هذه المرحلة.الرمز خاص بعملية التوليد
المرحلة 2 في المرحلة 2 في المرحلة: مرحلة التكميلبمجرد مرور القانون على التنفيذ الأساسي، تنتقل DESE إلىتُحَمَّلُ تُتَحَمُّلُ.
(التكرارات بالعجز)
هذالا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا، لا.
الشفرة لا تزال خاصة (ليس في السجل بعد) لكننا نقوم بتلميعها:أسماء أفضل
دعمالهيكل المكنسي
انخفاض
تحسين الأداءالشكل لم يعد سائلاً
نحن نعرف ما نبنيه.
اختبارات الوحدة النظامية.
(أ) إطار الاختبارات:*أمثلة الميزات المُعِيَّة (الإحالة)*حالات الطوارئ التي اكتُشفت خلال المرحلة 2
خصائص الأداء التي جرى قياسهاثمفقط إذا كانت الاختبارات تمر
،المدونة هي:
ذاكرة
# I know what sort() should do. Tests first? Sure!
def test_sort_empty_list():
assert sort([]) == []
def test_sort_single_element():
assert sort([5]) == [5]
def test_sort_multiple_elements():
assert sort([3, 1, 2]) == [1, 2, 3]
مضافا إلىالسجل:
في حالات سير العمل في المستقبل
درجات جودة الجودة
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.