Menulis aplikasi Django pertama anda, bagian 5

Tutorial ini mulai dimana Tutorial 4 ditinggalkan. Kami telah membangun aplikasi jejak pendapat jaringan, dan kami akan sekarang membuat otomatis percobaan untuknya.

Memperkenalkan percobaan otomatis

Apakah percobaan otomatis?

Percobaan adalah kebiasaan sederhana yang memeriksa pekerjaan dari kode anda.

Percobaan beroperasi di tingkatan berbeda. Beberapa percobaan mungkin berlaku ke rincian kecil (apakah cara model khas mengembalikan nilai sesuai diharapkan?) selama lainnya menguji operasi keseluruhan dari perangkat keras (apakah urutan dari masukan pengguna di situs menghasilkan hasil yang diinginkan?). Itu tidak berbeda dari beragam percobaan anda lakukan sebelumnya di Tutorial 2, menggunakan shell untuk menguji kebiasaan cara, atau menjalankan aplikasi dan memasukkan data untuk diperiksa bagaimana kebiasaannya.

Apa perbedaan di percobaan otomatis dimana percobaan bekerja selesai untuk anda oleh sistem. Anda membuat kumpulan percobaan sekali, dan lalu ketika anda membuat perubahan ke aplikasi anda, anda dapat memeriksa kode anda masih bekerja seperti anda inginkan aslinya, tanpa harus melakukan percobaan manual memakan waktu.

Mengapa anda butuh membuat percobaan

Jadi mengapa membuat percobaan, dan jenapa sekarang?

Anda mungkin merasa bahwa anda sangat cukup hanya belajar Python/Django, dan tidak mempunyai hal lain untuk belajar dan melakukan nampak luar biasa dan mungkin tidak perlu. Setelah semua, aplikasi jejak pendapat bekerja sangat gembira sekarang; melalui masalah dari pembuatan percobaan otomatis tidak akan membuatnya bekerja lebih baik. Jika membuat aplikasi jejak pendapat adalah hal terakhir dari pemrograman Django anda pernah lakukan, lalu benar, anda tidak butuh membuat percobaan otomatis. Tetapi, jika itu bukan kasusnya, sekarang adalah waktu yang tepat untuk belajar.

Percobaan akan menyelematkan waktu anda

Sampai titik tertentu, ‘memeriksa itu kelihatannya bekerja’ akan menjadi percobaan memuaskan. Di lebih aplikasi menakjubkan, anda mungkin mempunyai lusinan interaksi rumit antara komponen.

Sebuah perubahan di siapapun dari komponen itu dapat mempunyai konsekuensi tidak diharaokan di kebiasaan aplikasi. Memeriksa itu dia ‘kelihatan bekerja’ dapt berarti melalui fungsi kode anda dengan 20 macam berbeda dari data percobaan anda hanya untuk memastikan anda tidak merusak sesuatu - tidak baik menggunakan waktu anda.

Itu terutama benar ketika percobaan otomatis dapat melakukan ini untuk anda dalam hitungan detik. Jika sesuatu berjalan salah, percobaan akan juga membantu mencirikan kode yang menyebabkan kebiasaan tidak diharapkan.

Terkadang dia kelihatan bertugas untuk menyobek air mata anda jauh dari produktif anda, bekerja pemrograman kreatif untuk menghadapi bisnis tidak menarik dan tidak menggairahkan dari percobaan penulisan terutama ketika anda mengetahui kode anda bekerja dengan benar.

Bagaimanapun, tugas dari menulis percobaan adalah banyak lebih mengisi daripada menghabiskan berjam-jam mencoba aplikasi anda secara manual atau mencoba mencirikan penyebab dari masalah baru yang diperkenalkan.

Percobaan tidak hanya mencirikan masalah, mereka mencegah masalah

Adalah sebuah kesalahan berpikir percobaan hanya aspek negatif dari pengembangan.

Tanpa percobaan, tujuan atau kebiasaan dimaksud dari aplikasi mungkin agak buram. Bahkan ketika itu kode anda sendiri, anda akan terkadang menemukan diri anda mangaduk-aduknya dan mencoba menemukan apa sebenarnya yang dia lakukan.

Percobaan merubah itu; mereka menyalakan kode anda dari dalam, dan ketika sesuatu menjadi salah, mereka fokus menyalakan bagian yang berjalan salah - bahkan jika anda belum menyadarinya telah berjalan salah.

Percobaan membuat kode anda lebih menarik

Anda mungkin telah membuat potongan hebat dari perangkat lunak, tetapi anda akan menemukan bahwa banyak pengembang lain akan dengan mudah menolak untuk melihatnya karena dia kurang percobaan; tanpa percobaan, mereka tidak akan mempercayainya. Jacob Kaplan-Moss, satu dari pengembang Django, mengatakan “Kode tanpa percobaan adalah rusak oleh rancangan.”

Bahwa pengembang lain ingin melihat percobaan di perangkat lunak anda sebelum mereka mengambilnya secara sungguh-sungguh adalah alasan lain untuk anda untuk memulai menulis percobaan.

Percobaan membantu tim bekerja bersama

Titik sebelumnya ditulis dari sudut pandang dari pengembang tunggal merawat sebuah aplikasi. Aplikasi rumit akan dirawat oleh tim. Jaminan percobaan dimana rekan tidak sengaja merusak kode anda (dan bahwa anda tidak merusak kode mereka tanpa diketahui). Jika anda ingin membuat hidup seperti pemrogram Django, anda harus menjadi bagus pada penulisan percobaan!

Strategi percobaan dasar

Terdapat banyak cara untuk mendekatkan penulisan percobaan

Beberapa pemrogram mengikuti ketertiban dipanggil “test-driven development”; mereka sebenarnya menulis percobaan mereka sebelum mereka menulis kode mereka. Ini mungkin kelihatan kontra-intuitif, tetapi kenyataannya dia mirip pada apa yang paling orang sering lakukan: mereka menggambarkan masalah, lalu membaut beberapa kode untuk mengatasinya. Pengembangan uji-coba dengan mudah menyusun masalah di kasus percobaan Phyton.

Lebih sering, pendatang baru utnuk mencoba akan membuat beberapa kode dan kemudan memutuskan bahwa itu harus mempunyai beberapa percobaan. Mungkin itu akan lebih baik untuk menulis beberapa percobaan lebih awal, tetapi itu tidak pernah terlampat untuk mulai.

Terkadang adalah sangat sulit mencari tahu dimana untuk mulai dengan menulis percobaan. Jika anda telah menulis beberapa ribu baris Phyton, memilih sesuatu utnuk dicoba mungkin tidak mudah. Di kasus seperti itu, adalah bermanfaat untuk menulis percobaan pertama anda lain kali anda membuat perubahan, salah satu anda menambahkan fitur arau memperbaiki kesalahan.

Jadi mari kita melakukannya segera.

Menulis percobaan pertama kami

Kami mencirikan kesalahan

Untungnya, terdapat kesalahan sedikit di aplikasi polls untuk kami perbaiki segera: cara Question.was_published_recently() mengembalikan True jika Question telah diterbitkan dalam hari terakhir (yang benar) tetapi juga jika bidang pub_date Question di masa depan (yang tentu tidak).

Untuk memeriksa jika kesalahan benar ada, gunakan Admin buat pertanyaan dimana tanggalnya berada di masa datang dan periksa cara menggunakan shell:

>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> # create a Question instance with pub_date 30 days in the future
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # was it published recently?
>>> future_question.was_published_recently()
True

Sejak hal-hal di masa depan tidak ‘baru terjadi’, hal ini jelaslah salah.

Buat percobaan untuk membuka kesalahan

Apa yang kita telah lakukan di shell untuk mencoba masalah adalah sebenarnya kami dapat lakukan di percobaan otomatis, jadi mari kita rubah itu menjadi percobaan otomatis.

Tempat biasa untuk percobaan aplikasi adalah di berkas aplikasi tests.py; sistem percobaan akan otomatis menemukan percobaan di berkas apapun yang namanya dimulai dengan test.

Taruh berikut di berkas tests.py di aplikasi polls :

polls/tests.py
import datetime

from django.utils import timezone
from django.test import TestCase

from .models import Question


class QuestionMethodTests(TestCase):

    def test_was_published_recently_with_future_question(self):
        """
        was_published_recently() should return False for questions whose
        pub_date is in the future.
        """
        time = timezone.now() + datetime.timedelta(days=30)
        future_question = Question(pub_date=time)
        self.assertEqual(future_question.was_published_recently(), False)

Apa yang kita lakukan disini adalah membuat sebuah subkelas django.test.TestCase dengan cara yang membuat instance Question dengan pub_date di masa datang. Kami lalu memeriksa keluaran dari was_published_recently() - yang seharusnya menjadi False.

Menjalankan percobaan

Di terminal, kami dapat menjalan percobaan:

$ python manage.py test polls

dan anda akan lihat sesuatu seperti:

Creating test database for alias 'default'...
F
======================================================================
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionMethodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
    self.assertEqual(future_question.was_published_recently(), False)
AssertionError: True != False

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
Destroying test database for alias 'default'...

Apa yang terjadi adalah ini:

  • python manage.py test polls mencari percobaan di aplikasi polls

  • itu menemukan subkelas dari kelas django.test.TestCase

  • itu membuat basisdata khusus untuk tujuan percobaan

  • Itu mencari cara percobaan - satu yang namanya dimulai dengan test

  • di test_was_published_recently_with_future_question dia membuat sebuah instance Question yang bidang pub_date adalah 30 hari di masa depan

  • ... dan menggunakan cara assertEqual(), dia menemukan bahwa was_published_recently() mengembalikan True, meskipun kami menginginkannya mengembalikan False

Percobaan menginformasikan kami yang mana percobaan gagal dan bahkan baris di mana kegagalan muncul.

Memperbaiki kesalahan

Kami sudah mengetahui bahwa masalahnya adalah: Question.was_published_recently() harus mengembalikan False jika pub_date nya berada di masa depan. Merubah cara di models.py, sehingga dia hanya mengembalikan True jika tanggal juga berada di masa lampau:

polls/models.py
def was_published_recently(self):
    now = timezone.now()
    return now - datetime.timedelta(days=1) <= self.pub_date <= now

dan jalankan percobaan kembali:

Creating test database for alias 'default'...
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK
Destroying test database for alias 'default'...

Setelah mengenali sebuah bug, kami menulis tes untuk menemukannya dan memperbaiki bug yang ada di dalam kode sehingga tes yang kami buat dapat berjalan lancar.

Banyak hal lain mungkin menjadi salah dengan aplikasi kami di masa depan, tetapi kami dapat memastikan bahwa tidak secara sengaja memunculkan kembali kesalahan ini, karena menjalankan percobaan akan memerpingati kami segera. Kami dapat mempertimbangkan bagian kecil ini dari aplikasi berpikir dengan aman selamanya.

Percobaan lebih luas

Selama kami disini, kami dapat lebih jauh berpikir cara was_published_recently(); kenyataannya, dia akan sangat memaslukan jika dalam memperbaiki satu kesalahan kami telah memunculkan yang lain.

Tambah dua lagi cara percobaan ke kelas yang sama, untuk mencoba kebiasaan dari cara lebih menyeluruh:

polls/tests.py
def test_was_published_recently_with_old_question(self):
    """
    was_published_recently() should return False for questions whose
    pub_date is older than 1 day.
    """
    time = timezone.now() - datetime.timedelta(days=30)
    old_question = Question(pub_date=time)
    self.assertEqual(old_question.was_published_recently(), False)

def test_was_published_recently_with_recent_question(self):
    """
    was_published_recently() should return True for questions whose
    pub_date is within the last day.
    """
    time = timezone.now() - datetime.timedelta(hours=1)
    recent_question = Question(pub_date=time)
    self.assertEqual(recent_question.was_published_recently(), True)

Dan sekarang kami mempunyai tiga percobaan yang menegaskan bahwa Question.was_published_recently() mengembalikan nilai bijaksana untuk pertanyaan masa lampau, saat ini, dan masa depan.

Lagi, polls adalah aplikasi sederhana, tetapi bagaimanapun rumit dia tumbuh di masa depan dan apapun kdoe lain yang berinteraksi dengan nya, kami sekarang mempunyai beberapa jaminan bahwa cara kami telah tulis percobaan untuk akan berperilaku di jalur yang diharapkan.

Percobaan tampilan

Aplikasi jejak pendapat cukup tidak diskriminatif: dia akan menerbitkan pertanyaan apapun, termasuk satu dimana bidang pub_date terletak di masa depan. Kami harus meningkatkan ini. Pengaturan pub_date di masa depan berarti bahwa Pertanyaan di terbitkan pada saat itu, tetapi tidak terlihat sampai saat itu.

Sebuah percobaan untuk tampilan

Ketika kami memperbaiki kesalahan diatas, kami menulis percobaan dahulu dan lalu kode untuk memperbaikinya. Kenyataannya bahwa sebuah contoh sederhana dari pengembangan uji-coba, tetapi dia tidak terlalu penting urutan mana kami melakukan pekerjaan.

Di percobaan pertama anda, kami fokus lebih dekat pada kebiasaan internal dari kode. Untuk percobaan ini, kami ingin memeriksa kebiasaannya seperti akan berpengalaman oleh pengguna melalui perambah jaringan.

Sebelum kami mencoba memperbaiki apapun, mari kita melihat pada alat di pembuangan kami.

Klien percobaan Django

Django menyediakan percobaan Client untuk menirukan antarmuka pengguna dengan kode di tingkatan tampilan. Kami dapat menggunakannya di tests.py atau bahkan di shell.

Kami akan memulai lagi dengan shell, dimana kami butuh melakukan sepasang hal yang tidak penting di tests.py. Pertama adalah mengatur lingkungan percobaan di shell:

>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()

setup_test_environment() memasang cetakan pembangun yang akan mengizinkan kami memeriksa beberapa atribut tambahan dalam menanggapi seperto response.context bahwa sebaliknya tidak akan tersedia. Catat bahwa cara ini tidak mengatur basisdata percobaan, sehingga berikut akan jalan terhadap basisdata yang ada dan keluaran mungkin sedikit berbeda tergantung pada pertanyaan anda sudah buat.

Selanjutnya kami butuh mengimpor kelas klien percobaan (nanti di tests.py kami akan menggunakan kelas django.test.TestCase, yang datang dengan klien sendirinya, jadi ini tidak akan dibutuhkan):

>>> from django.test import Client
>>> # create an instance of the client for our use
>>> client = Client()

Dengan itu siap, kami dapat meminta klien melakukan beberapa pekerjaan untuk kami:

>>> # get a response from '/'
>>> response = client.get('/')
>>> # we should expect a 404 from that address
>>> response.status_code
404
>>> # on the other hand we should expect to find something at '/polls/'
>>> # we'll use 'reverse()' rather than a hardcoded URL
>>> from django.core.urlresolvers import reverse
>>> response = client.get(reverse('polls:index'))
>>> response.status_code
200
>>> response.content
b'\n\n\n    <p>No polls are available.</p>\n\n'
>>> # note - you might get unexpected results if your ``TIME_ZONE``
>>> # in ``settings.py`` is not correct. If you need to change it,
>>> # you will also need to restart your shell session
>>> from polls.models import Question
>>> from django.utils import timezone
>>> # create a Question and save it
>>> q = Question(question_text="Who is your favorite Beatle?", pub_date=timezone.now())
>>> q.save()
>>> # check the response once again
>>> response = client.get('/polls/')
>>> response.content
b'\n\n\n    <ul>\n    \n        <li><a href="/polls/1/">Who is your favorite Beatle?</a></li>\n    \n    </ul>\n\n'
>>> # If the following doesn't work, you probably omitted the call to
>>> # setup_test_environment() described above
>>> response.context['latest_question_list']
[<Question: Who is your favorite Beatle?>]

Memperbaiki tampilan kami

Daftar jejak pendapat menunjukkan jejak pendapat yang belum diterbitkan (yaitu itu yang mempunyai pub_date di masa depan). Mari kita perbaiki itu.

Di Tutorial 4 kami memperkenalkan tampilan berdasarkan-kelas, berdasarkan pada ListView:

polls/views.py
class IndexView(generic.ListView):
    template_name = 'polls/index.html'
    context_object_name = 'latest_question_list'

    def get_queryset(self):
        """Return the last five published questions."""
        return Question.objects.order_by('-pub_date')[:5]

Kami butuh merubah cara get_queryset() dan merubahnya sehingga dia juga memeriksa tanggal dengan membandingkannya dengan timezone.now(). Pertama kami butuh menambahkan sebuah impor:

polls/views.py
from django.utils import timezone

dan lalu kami harus merubah cara get_queryset seperti begitu:

polls/views.py
def get_queryset(self):
    """
    Return the last five published questions (not including those set to be
    published in the future).
    """
    return Question.objects.filter(
        pub_date__lte=timezone.now()
    ).order_by('-pub_date')[:5]

Question.objects.filter(pub_date__lte=timezone.now()) mengembalikan queryset mengandung Question dimana pub_date kurang dari atau sama dengan - yaitu, lebih awal dari atau sama dengan - timezone.now.

Menguji tampilan baru kami

Sekarang anda dapat memuaskan diri anda sendiri bahwa kebiasaan ini sesuai yang diharapkan dengan menyalakan peladen berjalan, memuat situs ke perambah anda, membuat Questions dengan tanggal di masa lalu dan depan, dan memeriksa bahwa hanya mereka yang telah diterbitkan akan ditampilkan. Anda tidak ingin melakukan itu setiap waktu tunggal anda buat perubahan apapun yang mungkin mempengaruhi ini - jadi mari kita membaut sebuah eprcobaan, berdasarkan pada sesi shell kami diatas.

Tambah berikut ke polls/tests.py:

polls/tests.py
from django.core.urlresolvers import reverse

dan kami akan membuat fungsi jalan pintas untuk membuat pertanyaan dan juga kelas percobaan baru:

polls/tests.py
def create_question(question_text, days):
    """
    Creates a question with the given `question_text` and published the
    given number of `days` offset to now (negative for questions published
    in the past, positive for questions that have yet to be published).
    """
    time = timezone.now() + datetime.timedelta(days=days)
    return Question.objects.create(question_text=question_text, pub_date=time)


class QuestionViewTests(TestCase):
    def test_index_view_with_no_questions(self):
        """
        If no questions exist, an appropriate message should be displayed.
        """
        response = self.client.get(reverse('polls:index'))
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_index_view_with_a_past_question(self):
        """
        Questions with a pub_date in the past should be displayed on the
        index page.
        """
        create_question(question_text="Past question.", days=-30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_index_view_with_a_future_question(self):
        """
        Questions with a pub_date in the future should not be displayed on
        the index page.
        """
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_index_view_with_future_question_and_past_question(self):
        """
        Even if both past and future questions exist, only past questions
        should be displayed.
        """
        create_question(question_text="Past question.", days=-30)
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_index_view_with_two_past_questions(self):
        """
        The questions index page may display multiple questions.
        """
        create_question(question_text="Past question 1.", days=-30)
        create_question(question_text="Past question 2.", days=-5)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question 2.>', '<Question: Past question 1.>']
        )

Mari kita lihat beberapa ini lebih dekat.

Pertama adalah fungsi jalan pintas pertanyaan, create_question, utuk mengambil beberapa perulangan dari pengolahan membuat pertanyaan.

test_index_view_with_no_questions tidak membuat pertanyaan apapun, tetapi memeriksa pesan: “Tidak ada jejak pendapat tersedia.” dan memeriksa latest_question_list adalah kosong. Catat bahwa kelas django.test.TestCase menyediakan beberapa tambahan penonjolan cara. Di contoh ini, kami menggunakan assertContains() dan assertQuerysetEqual().

Di test_index_view_with_a_past_question, kami membuat pertanyaan dan memeriksa bahwa dia muncul di daftar.

Di test_index_view_with_a_future_question, kami membuat sebuah pertanyaan dengan pub_date dimasa depan. Basisdata di setel kembali untuk setiap cara percobaan, jadi pertanyaan pertama tidak lagi disana, dan jadi kembali indeks tidak harus mempunyai pertanyaan apapun di dalamnya.

Dan sebagainya, Sebenarnya, kami menggunakan percobaan untuk memberitahu cerita masukan admin dan pengalaman pengguna di situs, dan memeriksa bahwa oada setiap tahapan dan setiap perubahan baru dari sistem, hasil yang diharapkan diterbitkan.

Menguji DetailView

Apa yang telah kita kerjakan baik; meskipun pertanyaan masa depan tidak muncul di indeks, pengguna dapat masih mencapai mereka jika mereka tahu atau menebak URL yang tepat. Jadi kami butuh pembatas sama ke DetailView:

polls/views.py
class DetailView(generic.DetailView):
    ...
    def get_queryset(self):
        """
        Excludes any questions that aren't published yet.
        """
        return Question.objects.filter(pub_date__lte=timezone.now())

Dan tentu saja, kami akan menambahkan beberapa percobaan, utuk memeriksa Question itu yang pub_date berada di masa lampau dapat ditampilkan, dan satu itu dengan pub_date di masa datang tidak:

polls/tests.py
class QuestionIndexDetailTests(TestCase):
    def test_detail_view_with_a_future_question(self):
        """
        The detail view of a question with a pub_date in the future should
        return a 404 not found.
        """
        future_question = create_question(question_text='Future question.', days=5)
        url = reverse('polls:detail', args=(future_question.id,))
        response = self.client.get(url)
        self.assertEqual(response.status_code, 404)

    def test_detail_view_with_a_past_question(self):
        """
        The detail view of a question with a pub_date in the past should
        display the question's text.
        """
        past_question = create_question(question_text='Past Question.', days=-5)
        url = reverse('polls:detail', args=(past_question.id,))
        response = self.client.get(url)
        self.assertContains(response, past_question.question_text)

Ide untuk percobaan lebih

Kami seharusnya untuk menambahkan cara get_queryset mirip ke ResultsView dan membuat kelas percobaan baru untuk tampilan itu. Itu akan sangat mirip pada apa kami telah buat; faktanya akan ada banyak pengulangan.

Kami dapat juga memperbaiki aplikasi kami di cara lain, menambahkan percobaan selama perjalanan. Sebagai contoh, adalah gila bahwa Questions dapat diterbitkan di situs yang tidak mempunyai Choices. Jadi, tampilan kami dapat memeriksa untuk ini, dan tidak menyertakan Questions seperti itu. Percobaan kami akan membuat sebuah``Question`` tanpa Choices dan lalu mencoba bahwa dia tidak diterbitkan, sama halnya membuat Question mirip dengan Choices, dan mencoba bahwa telah diterbitkan.

Mungkin pengguna admin masuk harus diizinkan melihat Questions tidak terbit, tetapi bukan asli pengunjung. Kembali: apapun kebutuhan untuk ditambahkan ke perangkat lunak untuk menyelesaikan ini harus disertai dengan percobaan, apakah anda menulis percobaan dahulu dan lalu membuat kode melewati percobaan, atau bekerja logis di kode anda pertama dan lalu menulis percobaan untuk membuktikannya.

Pada beberapa titik anda terikat untuk melihat percobaan anda dan berharap apakah kode anda menderita dari percobaan gelembung, yang membawa kami kepada:

Ketika percobaan, lebih baik

Ini mungkin kelihatan bahwa percobaan kami tumbuh tidak terkendali. Pada tingkatan ini akan anda lebih kode di percobaan kami daripada di aplikasi kami, dan pengulangan tidak indah, dibandingkan ke keringkasan elegan dari sisa kode kami.

Itu tidak masalah. Biarkan mereka tumbuh. Untuk kebanyakan, anda dapat menulis percobaan sekali dan lalu melukapan tentang itu. Itu akan terus melakukan fungsi yang berguna ketika anda melanjutkan mengembangkan program anda.

Terkadang percobaan akan butuh diperbaharui. Menduga itu kami merubah tampilan kami sehingga hanya Questions dengan Choices yang diterbitkan. Dalam kasus itu, banyak dari percobaan kami yang ada akan gagal - *katakan ke kami tepatnya percobaan mana butuh dirubah untuk membawanya selalu terbaru, jadi pada tingkatan percobaan itu membantu menjaga diri mereka sendiri.

Yang terburuk, ketika anda melanjutkan mengembangkan, anda mungkin menemukan bahwa anda mempunyai beberapa percobaan yang sekarang berlebihan. Bahkan itu bukan masalah; dalam percobaan adalah hal bagus.

Selama percobaan anda menyadari diatur, mereka tidak akan menjadi tidak dapat diatur. Aturan-dari-jempol bagis termasuk mempunyai:

  • terpisah TestClass untuk setiap model atau tampilan

  • sebuah cara percobaan terpisah untuk setiap kumpulan kondisi anda ingin diuji

  • Nama cara percobaan yang menggambarkan fungsi mereka

Percobaan lebih jauh

Tutorial ini hanya memperkenalkan beberapa dasar dari percobaan. Terdapat urusan hebat anda dapat lakukan, dan sejumlah alat sangat berguna pada penyelesaian anda untuk mencapai beberapa hal sangat cakap.

Sebagai contoh, selama percobaan kami telah dicakupi beberapa dari logika internal dari model dan cara tampilan kami menerbitkan informasi, anda dapat menggunakan kerangka “di-perambah” seperti Selenium utnuk mencoba cara HTML anda sebenarnya membangun di perambah. Alat ini mengizinkan anda untuk memeriksa bukan hanya kebiasaan kode Django, tetapi juga, sebagai contoh, dari Javascript anda. Ini cukup sesuatu untuk melihat percobaan meluncurkan perambah, dan mulai berinteraksi dengan situs anda, sebagai jika menjadi manusia mengemudikannya! Django menyertakan LiveServerTestCase untuk memfasilitasi dengan alat seperti Selenium.

Jika anda mempunyai aplikasi rumit, anda mungkin ingin menjalankan percobaan otomatis dengan setiap penyerahan untuk tujuan dari perpaduan kelanjutan, sehingga kendali kualitas itu sendiri - setidaknya sebagian - otomatis.

Sebuah jalan bagus untuk menempatkan bagian belum dicoba dari aplikasi anda adalah memeriksa cakupan kode. Ini juga membantu mencirikan kode rapuh atau bahkan mati. Jika anda tidak dapat mencoba potongan kode, biasanya berarti kode harus diuraikan kembali atau dipindahkan. Cakupan akan membantu mencirikan kode mati. Lihat Perpaduan dengan coverage.py untuk rincian.

doc:Testing in Django </topics/testing/index> mempunyai informasi luas tentang percobaan.

Apa Selanjutnya?

Untuk rincian penuh di percobaan, lihat Percobaan di Django.

Ketika anda nyaman dengan percobaan tampilan Django, baca bagian 6 dari tutorial ini untuk mempelajari tentang pengelolaan berkas statis.

Back to Top