⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 c5064.htm

📁 GUI Programming with Python
💻 HTM
字号:
<HTML><HEAD><TITLE>Automatic testing with PyUnit</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.72"><LINKREL="HOME"TITLE="GUI Programming with Python: QT Edition"HREF="book1.htm"><LINKREL="UP"TITLE="Creating real applications with PyQt"HREF="p4627.htm"><LINKREL="PREVIOUS"TITLE="Setting an application icon"HREF="x5049.htm"><LINKREL="NEXT"TITLE="Starting out"HREF="x5102.htm"></HEAD><BODYCLASS="CHAPTER"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">GUI Programming with Python: QT Edition</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="x5049.htm"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="x5102.htm"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="CHAPTER"><H1><ANAME="CH9">Chapter 14. Automatic testing with PyUnit</A></H1><DIVCLASS="TOC"><DL><DT><B>Table of Contents</B></DT><DT><AHREF="c5064.htm#AEN5073">About unittests</A></DT><DT><AHREF="x5102.htm">Starting out</A></DT><DT><AHREF="x5120.htm">A first testcase</A></DT><DT><AHREF="x5171.htm">Collecting tests in a test suite</A></DT><DT><AHREF="x5202.htm">A more complicated test</A></DT><DT><AHREF="x5234.htm">Large projects</A></DT><DT><AHREF="x5255.htm">Testing signals and slots</A></DT><DT><AHREF="x5285.htm">Conclusion</A></DT></DL></DIV><P>In <AHREF="c4631.htm">Chapter 12</A>, we created an    application framework in which the GUI interface was separate from    the application logic. One of the reasons for this was to make it    easier to test the components in isolation. Testing your software    components separately is called unit-testing, and it has proven    over the past few years to be a very good way of ensuring software    quality. Python supports working with unit-tests out of the box:    since version 2.1, a special module,    <TTCLASS="FILENAME">unittest.py</TT>, is included in the standard    distribution. In this chapter, we will write a unittest for the    document module from the document-view framework.</P><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="AEN5073">About unittests</A></H1><P>Have you ever done maintenance on a large      application and broken something because you changed something,      somewhere? Or worse, only noticed the breakage when a user      mailed you? Have you ever begun writing an application, but were      unable to complete it because the whole castle of cards      collapsed due to excessive fragility?</P><P>It has probably happened to you, and it      certainly has happened to me. Testing software is a boring      chore, and besides, everything has to be finished yesterday, or      today at the latest. However, <SPAN><ICLASS="EMPHASIS">not</I></SPAN> testing      will cost you a lot of time, too, and it's more fun to program      than to bug-hunt. It would be best if automated testing could be      made part of the edit-compile-crash cycle.</P><P>This has occurred before to a lot of people,      but the honor of &#8216;inventing' automatic unit-testing      belongs to Erich Gamma and Kent Beck - familiar names to      developers everywhere. They started writing unit-test frameworks      for SmallTalk, moving on to Java and other languages.</P><P>The idea is simple but ingenuous: first the      developer writes his test, then the class that will make the      test work; the process is repeated until the created code fits      the application you're developing. All the while, you will get      instant feedback from a small GUI app that runs your tests and      shows you a green progressbar when everything works as intended,      and a horrible, unfriendly red progressbar when a test fails.      You can also run the unittests without a gui, but it isn't as      much fun.</P><DIVCLASS="MEDIAOBJECT"><P><DIVCLASS="CAPTION"><P>All is well - the bar is green!</P></DIV></P></DIV><DIVCLASS="MEDIAOBJECT"><P><DIVCLASS="CAPTION"><P>Back to the drawing board; the bar is red, tests      have failed!</P></DIV></P></DIV><P>Writing tests takes a bit of getting used-to,      and it <SPAN><ICLASS="EMPHASIS">is</I></SPAN> something more easily learned when      working together with someone who has done it before. However,      once you get around to it, it is definitely addictive.</P><P>Unit-testing using the      <TTCLASS="FILENAME">unittest.py</TT> framework also departs from      what people are used to doing when testing: namely, writing      scripts that simulate user input, such as mouse-clicks. Those      scripting solutions are quite often so fragile that they are      worse than useless. It is far better to explicitly code tests      for the back-end of your application, guaranteeing that the      interaction between backend and GUI is correct, as opposed to      trying to deduce bugs from apparent errors at the GUI      front.</P><P>In sum, the advantage of unit-testing is:      you know you can depend upon the behavior of your components,      and whenever you change a component, you will be alerted to that      change by failing tests. In short, you will be able to trust      your software at a relatively low level.</P><P>There a few disadvantages, too. You might      be lulled into a false sense of security: if you change your      unit-tests along with the code, then you can no longer be sure      that your components fit your system, for you have just changed      their behavior.  A unittest is a kind of contract about the      behavior your code exposes to the outside world. Changing the      contract one-sidedly is a guarantee for breaking      relations.</P><P>It's also quite difficult to find a good      division between unit-tests and functional tests. Functional      testing is mostly done from a user perspective; unit-tests test      the behavior of your classes, but functional tests test the      behavior of the application. There is currently no way to      automate functional testing.</P><P>Cynics have noted that the running of      unittests has negated all the progress made in creating fast      compilers, and even virtually compilation-less languages such as      Python. Indeed, running a full testsuite can take a long time.      Fortunately, <SPANCLASS="APPLICATION">Pyunit</SPAN> is very      fast.</P><P>Lastly, watching the bar stay green is      addictive in itself, and you might be tempted to run working      tests over and over again...</P></DIV></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="x5049.htm"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="book1.htm"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="x5102.htm"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Setting an application icon</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="p4627.htm"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Starting out</TD></TR></TABLE></DIV></BODY></HTML>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -