=== hggdh is now known as hggdh|away [02:15] any one recommend a good Dynamic DNS provider for website that uses gmail for the mail and a desktop for the webserver with a dynimic IP and also has ssl cert also has more then one subdomain I want to use and have show in the address by our own domain [02:45] hello [05:07] QUESTION: hi! Any idea when the logs for the previous sessions would be available? === thekorn_ is now known as thekorn [08:23] '; === dholbach_ is now known as dholbach === hggdh|away is now known as hggdh === david is now known as davfigue === daubers_ is now known as daubers [17:00] Hi, everyone ready for today's sessions? [17:00] I am :-) [17:00] Me too! [17:01] wooooo [17:01] o/ [17:01] what is today's session? [17:01] laga: ask mdz [17:01] https://wiki.ubuntu.com/UbuntuDeveloperWeek [17:01] Ok, today we're starting off with "Ask Matt" ... Matt will introduce himself and explain what he does [17:01] ah, right. [17:01] please ask your questions in #ubuntu-classroom-chat [17:01] hello, everyone [17:01] prefixed with QUESTION: and I will paste them here [17:01] take it away mdz! [17:02] my name is Matt Zimmerman [17:02] I've been involved with Ubuntu since its inception, and currently serve as the chairman of the Technical Board and as Ubuntu CTO for Canonical, Ubuntu's corporate sponsor [17:03] I'm happy to take questions about Ubuntu itself, its development, or Canonical [17:03] < krokosjablik> QUESTION: What are the current plans to provide more stability in the LTS releases (http://brainstorm.ubuntu.com/idea/7862/)? In reletaion to this, what do you think about the idea "LTS releases should be built upon the stable core of the previous release" (http://brainstorm.ubuntu.com/idea/11387/)? [17:04] this is an interesting topic, one where we're attempting something quite different from most distributions [17:04] since we continue to make full-fledged releases every six months, and don't have a separate branch of development, we work from the same code base to produce LTS as we do everything else [17:05] the primary difference, of course, is what we do *after* release: namely continue to maintain and support them for a longer term [17:06] we also make certain adjustments to our development plans to especially emphasize stability in those releases [17:06] for 6.06 LTS (dapper), we actually extended our release cycle to give us more time to work on shoring up some key subsystems [17:06] for 8.04, we produced a normal release on time, and followed it up with a very intensive point release effort, leading to 8.04.1 [17:08] this is a difficult tradeoff, as we want to provide the kind of predictability and stability that users want for the long term, but we also need to continue to keep up with the latest software for the benefit of everyday users who want that [17:09] suggestions like "skipping" a release and doing only stabilization work would mean disappointing a lot of people who want the latest GNOME, Firefox, etc. and are accustomed to coming to Ubuntu for that for years now [17:10] we are hearing the feedback, though, and will continue to make adjustments to how we do our releases in order to find the best balance [17:10] including some more ambitious plans which span multiple release cycles, about which I'll talk more in the future, once they're a bit more baked [17:11] < stefanlsd> QUESTION: What is Canonicals plan regarding getting more big name vendors to support their product on [17:11] Ubuntu. Most of our clients today are running RH or SLES because Oracle, DB2, SAP, Websphere etc is [17:11] supported on them. [17:11] whoops [17:11] jcastro: it's fine [17:12] this is an area we're very active in at Canonical, but it's also a very large ecosystem, so it will take time for Ubuntu to settle into a strong position there [17:12] large ISVs like the ones you mention don't take decisions like this lightly, and they're more comfortable working with companies and technologies which have been around for a longer time === RainCT is now known as RainCT_ [17:13] with Ubuntu, which hasn't yet turned four, we still have some way to go before we have the same standing as distributions which are more established with ISVs [17:14] DB2 has been certified on Ubuntu for some time, and a complete appliance is available for sale from Canonical [17:14] we have a very positive relationship with IBM and I expect more good things in the future [17:15] similarly, just a little while ago, we made a joint announcement with IBM to bundle their Open Collaboration Client (which includes Notes, Symphony etc.) [17:16] the trick is that for a given organization, there are a specific set of boxes to tick, and until we tick them all, there are some enterprises where it will be difficult to use Ubuntu [17:16] e.g. if we have DB2 but not SAP, someone who needs both may need to go elsewhere for now [17:16] but meanwhile, there are lots of places where Ubuntu is a great choice, even in those same companies but in different usage scenarios [17:17] most of our work in this area is with server ISVs at the moment, though there are some good things happening on the desktop side as well [17:18] < rick_h_> QUESTION: I see that intrepid is bumping the kernel to sync up with promises of RH/SuSE, has there been much reaction/action to the idea of syncing the major distros and is this a first step in showing Ubuntu's willingness to do some of the work involved? [17:18] the final decision hasn't been taken yet, but it looks increasingly like we'll stick with 2.6.27 for Intrepid [17:19] there were a variety of reasons for this, most of which have more to do with the kernel itself and how it meets our needs for Ubuntu than what other distributions are doing [17:19] however, it will be a great bonus if being in sync with them makes it easier for us to exchange patches, and means that the base kernel we use receives even more testing [17:20] we have had positive discussions with major open source projects about synchronization, but it's a very difficult proposition for the community as a whole, and it will take a long time to see whether the idea takes hold [17:20] it's a large community with a lot of momentum, and large-scale changes are necessarily slow [17:21] we are, generally speaking, agreeable to adapting our plans to fit into a synchronized scheme; Mark has said publicly that we would be willing to change the date of our next LTS release if it meant we could benefit from synchronization [17:22] as an early step, we're working in some cross-distribution forums to at least gather information about what everyone's plans are, and use that as a starting point to discuss how we could coordinate === zachr_ is now known as zmrow [17:23] (that mailing list is "distributions" on freedesktop.org if people want to follow along) [17:23] ironically, some of the early effects may be in DEsynchronization before we do more synchronization; mirror operators have complained about major distributions releasing very close together and overloading their links [17:23] so we'll try to make sure that we don't step on each other's toes, and continue to look for opportunities to get mutual benefit from a manageable level of change to our schedules [17:24] < fluteflute> QUESTION: Is there any chance of gaining work experience at Canonical? If so, who should I contact? (My message to webmaster@canonical.com has gone unanswered.) [17:24] Canonical is a fast-growing company, and we have quite a few job openings posted on http://webapps.ubuntu.com/employment/ [17:25] please note that webmaster@canonical.com is who you contact if you have job _openings_ you'd like to post which are related to Ubuntu: read the page carefully [17:25] there is a link to apply on each page for a specific job [17:25] < krokosjablik> QUESTION: Do you speak with Gnome/KDE (and another upstream) projects, so they also release _LTS_ versions in time with Ubuntu LTS? Are there any plans for this? [17:26] quite coincidentally, the next major GNOME release "3.0" falls around the same time as our next projected LTS [17:27] so that may be a good time for us to coordinate something, particularly if it takes longer than six months for GNOME to go through a round of extensive changes [17:28] many open source projects don't make plans more than 6-12 months in advance, if that, which makes it difficult to project that far in the future [17:28] I think we'll start to get more clarity on these possibilities next year [17:28] < Kurt> QUESTION: Just a curiosity, but will 9.04 be announced soon? I noticed that 8.04 was announced around this time last year. [17:29] yes, in fact an announcement is planned for early next week [17:29] the ever-popular question of what the code name will be will be answered at that time as well :-) [17:30] if you have ideas which you'd like to put forth for the 9.04 cycle, please put them into brainstorm [17:30] and review the items in there to help rank them [17:31] we will review the top items and use them to help set our direction for the release [17:31] < hggdh> QUESTION: although sort of answered, any more hard data on integration with major suppliers (like Oracle, etc) [17:32] any such discussions in progress with partners or potential partners would be confidential [17:32] I would not be able to discuss such information which is not already public about our activities with those companies [17:32] apologies [17:33] mdz, fair. I understand. [17:33] QUESTION: artwork discussions are always heated and opinionated, can you discuss what the artwork plans are for intrepid? [17:34] we experimented with a fairly radical change in the theme earlier in the cycle (the darker theme) [17:35] however, we decided to work on that concept more before moving away from the basic 8.04 look [17:35] there's a lot of activity over on ubuntu-art if you want to follow it more closely [17:35] and it's true, things get pretty heated over there during development [17:36] one interesting change is that we've moved to a different theme engine to provide the technical foundations for the current theme [17:36] which should be more stable and maintainable in the long term [17:37] < hggdh> QUESTION: how are plans to base some upstreams in bzr? for example, Evolution ;-) [17:37] (I think this would be a great opportunity to talk about DistributedDevelopment) [17:37] open source projects have understandably strong opinions about which tools they choose to use [17:38] people get invested in a particular toolset which they have learned well and built their own custom tools on [17:38] it can be a lot of work to change [17:38] Question: any news about opensourcing launchpad ? [17:38] * tacone ducks [17:39] the GNOME project tries to standardize their tools to some extent, and most of its components use the same revision control system [17:39] there was quite a bit of discussion at GUADEC about moving to a distributed system, but as far as I know, this hasn't been decided yet, so we'll see what happens there [17:39] (Questions in #ubuntu-classroom-chat please) [17:40] it would be very good for Ubuntu if GNOME and other upstream projects move to distributed revision control [17:40] and I personally think Bazaar is a great choice, but there are a number of good ones out there [17:41] the more projects go distributed, the better the tools we can build to help us package and deliver their work to users efficiently [17:41] I'm very excited about the distributed development plan [17:41] it's something that many of us have wanted to build for a long time now [17:42] it's somewhat hard to believe that projects as large as Debian and Ubuntu use revision control only in limited ways [17:42] writing just a single software program without using revision control is considered strange [17:42] but creating a whole distribution out of thousands, without revision control, is a bit crazy :-) [17:43] we have a well developed toolset for the way we work today, though, and we hope to make the transition pretty seamless for developers who want to work in revision control [17:43] furthermore my hope is that putting all of Ubuntu in Bazaar will make it very easy for people to get started on contributing to the project [17:44] if you have a patch, you'll be able to commit it to your own branch, work on it there and get feedback, build it and put it into a PPA, and when it gets reviewed, it will be very easy for a MOTU or core developer to push it into Ubuntu [17:44] I find it much simpler than emailing patches around and filing a lot of bug reports [17:45] in the places where we're using revision control today, there is a lower barrier for contribution and it's less work for the maintainer of the package [17:45] as to your original question, I think we're making good progress, and our goal is to start to realize some concrete benefits from the work during the 9.04 development cycle [17:45] < mcisternas> QUESTION: How journalists can work in Ubuntu? Will there be more spaces for journalists in the community? [17:46] one of the great community success stories in Ubuntu is Ubuntu Weekly News, which recently passed its 100th issue [17:47] I'm very grateful to the folks who contribute to that publication and fill it with good content week after week [17:47] Full Circle magazine is a newer publication with a somewhat different audience and more of a print style [17:47] and I'm also very impressed with their work [17:48] journalists looking to get involved should probably talk to the Ubuntu News Team [17:48] whose mailing list is https://lists.ubuntu.com/mailman/listinfo/Ubuntu-news-team [17:49] they'll be able to give the most up to date and accurate information about what's happening and the opportunities to contribute [17:49] < hggdh> QUESTION: let's suppose my company uses, commercially, Ubuntu. Will the bugs we open be viewable by all, or would we have a restricted "Malone"? This is a question I have been asked when I proposed Ubuntu elsewhere... [17:50] Ubuntu itself, as you know, is an open community project, and so information about what we're doing, including the bugs we have, is publicly available [17:51] this is a bit scary sometimes for companies who are used to working in more closed environments, and they wonder whether using Ubuntu requires that they give up their privacy [17:51] companies who want to participate in the Ubuntu community are very welcome, but sometimes it's hard for them to understand where they fit in [17:52] they're used to dealing with other companies in the normal sorts of ways, and open development may not fit into their business or culture very easily [17:52] for example, many large companies need to go through extensive approval processes in order to release information into the public [17:53] I think it's important that companies who adopt open source learn about how it works and how to get involved in the usual ways [17:53] because the ability to get involved, influence the direction of the project, and follow development closely, are key benefits of using open source [17:53] and without them, companies won't get the full value that open source has to offer [17:54] however, for companies where this just isn't an option for whatever reason, Canonical can act as a sort of bridge [17:54] we can work with companies on standard commercial terms, sign non-disclosure agreements, etc. [17:54] and help them to open up the things that they can open [17:55] for example, if a commercial customer of ours is working on a particular bug with us, we can track the bug simultaneously in a private fashion and in the public Launchpad [17:56] so that anything we *can* put into the open system goes there, but we still have the ability to work with them and preserve confidentiality where they need it [17:56] with regard to your specific question, we do have the capability to offer private bug hosting for our commercial customers to help them do things like this [17:57] Ok we're running out of time, we have time for 2 more questions [17:57] < krokosjablik> QUESTION: Would you like consider more consolidation between Gnome and KDE like using only one platform - GTK or Qt? Is it realistic? [17:57] mdz, THANKS! This is a most important point for some of the companies I do contract work! [17:58] I think that consolidation is valuable where it makes development easier [17:59] sometimes, if one component is dominant, it will get more "love" from developers, and thus get better than if attention were divided among competing tools [17:59] however, it doesn't always work that way, and if everyone is working the same way, things don't get better because it's harder to create something new to displace it [17:59] so I think a certain amount of diversity is healthy [17:59] both systems have their merits, and where it's possible and sensible for the projects to collaborate on them, I think they will, and we've already seen evidence of that [18:00] there would be no point in trying to standardize by fiat; these things need to work themselves out organically in the community [18:00] KDE and GNOME are both strong communities capable of doing that [18:00] ok that's it folks. [18:01] I think that's all the time we have, there's another session starting now [18:01] thanks! [18:01] Thanks matt for hosting the session, and thanks everyone for their questions! [18:01] thanks very much for your questions [18:01] liw: you sir, are up next! [18:01] if you have more, take them to the ubuntu-devel-discuss mailing list and I and others will answer as we can [18:01] jcastro, yay! [18:02] jcastro, how do you want to work this, shall I wait a bit or just start now? [18:02] up to you, it's your hour. :) [18:02] Though a few minutes so everyone can go to the bathroom or something is always appreciated. :D [18:02] I'll wait for 180 seconds, then [18:03] in the mean while: jcastro, will you or someone be around to relay questions from -chat? [18:06] ok, let's start [18:06] Welcome, everyone. The goal of this session is to introduce the Python unittest library and the coverage.py code coverage measurement tool. [18:07] I will do this by walking through the development of a simple command line program to compute md5 checksums for programs. [18:07] I assume everyone in the audience has a basic understanding of Python. [18:07] If you have questions, please ask them in #ubuntu-classrom-chat, prefixed with "QUESTION". [18:07] I would also appreciate if someone volunteered to feed the questions to me one by one. [18:07] (now breathe a bit and read that :) [18:08] The exaple program I will develop will be similar to the md5sum program. [18:08] It gets some filenames on the command line and writes out their MD5 checksum. [18:08] For example: checksum foo.txt bar.txt [18:08] This might output something like this: [18:08] d3b07384d113edec49eaa6238ad5ff00 foo.txt [18:08] c157a79031e1c40f85931829bc5fc552 bar.txt [18:09] is anyone following this or am I going too fast? [18:09] I volunteer for relaying [18:09] Myrtti, thank you [18:09] I will develop this program using "test driven development", which means that you write the tests first. [18:10] 'http://en.wikipedia.org/wiki/Test_Driven_Development gives an overview of TDD for those who want to learn more. [18:10] For this tutorial, we will merely assume that writing tests first is good because it is easier to write tests for all parts of your code. [18:10] For the checksumming application, we will need to compute the checksum for some file, so let's start with that. [18:10] http://paste.ubuntu.com/43675/ [18:10] That has the unit test module. [18:11] In the real program, we will have a class called FileChecksummer, which will be given an open file when it is created. [18:11] It will have a method "compute", which computes the checksum. [18:11] The checksum will be stored in the "checksum" attribute. [18:11] To start with, the "checksum" attribute will be None, since we have not yet computed the checksum. [18:11] The "compute" method will set the "checksum" attribute when it has computed the checksum. [18:11] (This is not necessarily a great design, for which I apologize, but this is an example of writing tests, not of writing great code) [18:11] In the unit test, we check that this is true: that "checksum" is None at the start. [18:12] < geser> QUESTION: there are several unittest frameworks for Python out there. What are the most important differences between them? [18:12] I'll answer the question in a minute [18:12] The Python unittest module is inspired by the Java JUnit framework. [18:12] JUnit has inspired implementations in many languages, and these frameworks are collectively known as xUnit. [18:12] See http://en.wikipedia.org/wiki/XUnit for more information. [18:13] there are at least two other modules for automated testing in the Python standard library: doctest and test. [18:13] unittest is the only one I have any real experience in. back when I started writing unit tests with Python, doctest scared me, and I don't know if test even existed then [18:14] as far as I understand, the choice between doctest and unittest is mostly a matter of taste: it depends on how you want to write the tests [18:15] I like unittest's object oriented approach; doctest has an approach where you paste a Python command prompt session into a docstring and doctest runs the code and checks that the output is identical [18:15] so it's good to look at both and pick the one that you prefer; sorry I can't give a more definite answer [18:16] The example above (see the paste.ubuntu.com URL I pasted) shows all the important parts of unittest. [18:16] The tests are collected into classes that are derived from the unittest.TestCase class. [18:16] Each test is a method whose name starts with "test". [18:16] There can be some setup work done before each test, and this is put into the "setUp" method. [18:16] In this example, we create a FileChecksummer object. [18:16] < Salze> QUESTION: is that a convention that the testclass is the original classname plus "tests"? [18:16] Salze, yes, that is one convention; that naming is not enforced, but lots of people seem to use it [18:17] continuing [18:17] Similarly, there can be work done after each test, and this is put into the "tearDown" method, but we don't need that in this example. [18:17] "setUp" is called before each test method, and "tearDown" after each test method. [18:17] There can be any number of test methods in a TestCase class. [18:17] The final bit in the example calls unittest.run to run all tests. [18:17] unittest.run automatically finds all tests. [18:17] that's all about the test module. any questions on that? take a minute (and tell me if you need more time), it's good to understand it before we continue [18:19] no questions? let's continue then [18:19] http://paste.ubuntu.com/43676/ [18:19] That's the actual code. [18:20] As you can see, it is very short. [18:20] That is how test driven development works: first you write a test, or a small number of tests, and then you write the shortes possible code to make those tests pass. [18:20] Let's see if they do. [18:20] To run the tests do this: pyhon checksum_tests.py [18:20] You should get the following output: [18:20] liw@dorfl$ python checksum_tests.py [18:20] . [18:20] ---------------------------------------------------------------------- [18:20] Ran 1 test in 0.000s [18:20] [18:20] OK [18:20] Everyone please try that, while I continue slowly. [18:21] The next step is to make FileChecksummer to actually compute a checksum. [18:21] First we write the test. [18:21] http://paste.ubuntu.com/43677/ [18:21] that's the new version of the test module [18:21] it adds the testComputesAChecksum method [18:21] Then we run the test. [18:22] liw@dorfl$ python checksum_tests.py [18:22] F. [18:22] ====================================================================== [18:22] FAIL: testComputesAChecksum (__main__.FileChecksummerTests) [18:22] ---------------------------------------------------------------------- [18:22] Traceback (most recent call last): [18:22] File "checksum_tests.py", line 18, in testComputesAChecksum [18:22] self.assertNotEqual(self.fc.checksum, None) [18:22] AssertionError: None == None [18:22] [18:22] ---------------------------------------------------------------------- [18:22] That's not so good. [18:22] The test does not pass. [18:22] That's because we only wrote the test, not the code. [18:22] This, too, is how test driven development works. [18:22] We write the test, and then we run the test. [18:22] And now check that the test fails in the right way. [18:22] And it does: it fails because the checksum attribute is None. [18:22] The test might have failed because we did not have a compute method, or because we misspelt the checksum attribute. [18:22] Since we did not, the test is OK, and we write the code next. [18:22] http://paste.ubuntu.com/43679/ [18:23] that's the new code, it modifies the compute() method [18:23] Please run the test and see that it works. [18:23] < davfigue> QUESTION: what is the package for cheksum module ? [18:24] davfigue, the checksum module comes from http://paste.ubuntu.com/43679/ -- save that to a file called checksum.py [18:24] and update the file with newer versions as I get to them [18:24] did anyone run the modifed code successfully through the tests? [18:24] < thekorn> QUESTION: what's your experience, where should I put the test code, in the module itself or in a seperate tests/ sub-directory? [18:25] thekorn, in my experience, because of the way I run my tests, it is best to keep a module foo.py and its tests in foo_tests.py in the same directory; while I haven't tried nose (python-nose), I use another similar tool and it benefits from keeping them together [18:26] thekorn, I also find that as aprogrammer it's easier to have things together [18:26] I'm going to hope the code passes through tests for others, and continue [18:26] If you look at the code, you see how I cheated: I only wrote as much code as was necessary to pass the test. [18:26] In this case, it was enough to assign any non-None value to checksum. [18:27] That's OK, that's part of how test driven development works. [18:27] You write a test and then a little code and then you start again. [18:27] This way, you do very, very small iterations, and it turns out that for many people, including me, that means the total development speed is higher than if you skip writing the tests, or write a lot of code at a time. [18:27] That's because if you write a lot of code before you test it, it's harder to figure out where the problem is. [18:27] If you only write one line at a time, and it breaks, you know where to look. [18:27] So the next step is to write a new test, something to verify that compute() computes the right checksum. [18:27] Since we know the input, we can pre-compute the correct answer with the md5sum utility. [18:27] liw@dorfl$ echo -n hello, world | md5sum - [18:27] e4d7f1b4ed2e42d15898f4b27b019da4 - [18:27] Changing the test give this: [18:28] http://paste.ubuntu.com/43680/ [18:28] Again, tests fail. [18:28] It's time to fix the code. [18:28] http://paste.ubuntu.com/43681/ [18:28] < Salze> QUESTIONS: writing all the tests (one can think of) at once would be a "valid" approach to TDD, too? Or not? [18:29] Salze, it's a valid approach, if it works for you :) I find that writing a large number of tests at once results in me writing a lot of code at once, and a lot of bugs [18:29] but sometimes it's ok to write a lot of tests, to test all the aspects of a small amount of tricky code [18:30] for example, if the function checks that a URL well-formed, it's ok to write all tests at once, adn then write the one-line regular expression [18:30] Next we will write a main program to let us compute checksums for any files we may want. [18:30] Sometimes it feels like a lot of work to write tests all the time, so I'm going pretend I'm lazy and skip writing the tests now. [18:30] (note: _pretend_ :) [18:30] After all, the checksumming is the crucial part of the program, and we've alredy written tests for that. [18:30] The rest is boilerplate code that is very easy to get right. [18:30] http://paste.ubuntu.com/43682/ [18:30] That's the finished application. [18:31] All tests pass, and everything is good. [18:31] Oops, no it isn't. [18:31] If you try to actually run the application, you get the wrong output: [18:31] liw@dorfl$ python checksum.py foo.txt bar.txt [18:31] None foo.txt [18:31] None bar.txt [18:31] I forgot to call compute! [18:31] See, this is what happens when I am lazy. [18:31] I make bugs. [18:31] Fixing... [18:31] Still too lazy to write a test. [18:31] http://paste.ubuntu.com/43683/ [18:32] that's really the finaly checksum.py I hope [18:32] To test it, I compare its output with md5sum's. [18:32] liw@dorfl$ python checksum.py foo.txt bar.txt [18:32] d3b07384d113edec49eaa6238ad5ff00 foo.txt [18:32] c157a79031e1c40f85931829bc5fc552 bar.txt [18:32] liw@dorfl$ md5sum foo.txt bar.txt [18:32] d3b07384d113edec49eaa6238ad5ff00 foo.txt [18:32] c157a79031e1c40f85931829bc5fc552 bar.txt [18:32] Both programs give the same output, so everything is OK. [18:32] * liw makes a significant pause, because this is an important moment [18:32] See what happened there? [18:32] I stopped writing automated tests, so now I have to test things by hand. [18:32] In a big project, how often can I be bothered to test things by hand? [18:32] Not very often, because I'm lazy. [18:33] By writing automated tests, I can be more lazy. [18:33] This is why it's good for programmers to be lazy: they will work their asses off to only do something once. [18:33] everyone with me so far? [18:34] Suppose we come back to this checksumming program later. [18:34] We see that there is some automated testing, but we can't remember how complete it is. [18:34] (side note: the md5 module is going to be deprecated in future python versions, the hashlib module is the real module to use) [18:34] In this example, it is obvious that it isn't very complete, but for a big program, it is not so obvious. [18:35] coverage.py is a tool for measuring that. [18:35] It is packaged in the python-coverage package. [18:35] To use it, you run the test with it, like this: [18:35] liw@dorfl$ python -m coverage -x checksum_tests.py [18:35] .. [18:35] ---------------------------------------------------------------------- [18:35] Ran 2 tests in 0.001s [18:35] [18:35] OK [18:35] See, there is no change in the output. [18:35] However, there is a new file, .coverage, which contains the coverage data. [18:35] To get a report, run this: [18:35] liw@dorfl$ python -m coverage -r [18:35] Name Stmts Exec Cover [18:35] ---------------------------------------------------------------- [18:35] /usr/lib/python2.5/StringIO 175 37 21% [18:35] /usr/lib/python2.5/atexit 33 5 15% [18:35] /usr/lib/python2.5/getopt 103 5 4% [18:35] /usr/lib/python2.5/hashlib 55 15 27% [18:35] /usr/lib/python2.5/md5 4 4 100% [18:35] /usr/lib/python2.5/posixpath 219 6 2% [18:35] /usr/lib/python2.5/threading 562 1 0% [18:36] /usr/lib/python2.5/unittest 430 238 55% [18:36] /var/lib/python-support/python2.5/coverage 522 3 0% [18:36] : File '/home/liw/Canonical/udw-python-unittest-coverage-tutorial/' not Python source. [18:36] checksum 20 13 65% [18:36] checksum_tests 14 14 100% [18:36] ---------------------------------------------------------------- [18:36] TOTAL 2137 341 15% [18:36] oops, that was long [18:36] Stmts is the total number of statements in each module, Exec is how many we have executed, and Cover is how many percent of all statements we have covered [18:36] This contains all the Python standard library stuff as well. [18:36] We can exclude that: [18:36] liw@dorfl$ python -m coverage -r -o /usr,/var [18:36] (skipping long output) [18:36] TOTAL 34 27 79% [18:37] This shows that only 27 statements of a total of 34 are covered by the testing. [18:37] The line with "class '__main__.CoverageException'>" is a bug in the hardy version of coverage.py, please ignore it. [18:37] To get a list of the lines that are missing, add the -m option: [18:37] liw@dorfl$ python -m coverage -rm -o /usr,/var [18:37] Name Stmts Exec Cover Missing [18:37] ---------------------------------------------- [18:37] : File '/home/liw/Canonical/udw-python-unittest-coverage-tutorial/' not Python source. [18:37] checksum 20 13 65% 22-27, 31 [18:37] checksum_tests 14 14 100% [18:37] ---------------------------------------------- [18:37] TOTAL 34 27 79% [18:37] We're missing lines 22-27 and 31 from checksum.py. [18:37] That's the ChecksumApplication class (it's run method) and the main program. [18:38] Now, if we wanted to, we could add more tests, and get 100% coverage. [18:38] And that would be good. [18:38] However, sometimes it is not worth it to write the tests. [18:38] In that case, you can mark the code as being outside coverage testing. [18:38] http://paste.ubuntu.com/43684/ [18:38] See the "#pragma: no cover" comments? That's the magic marker. [18:38] We now have 100% statement coverage. [18:38] Experience will tell you what things it's worthwhile to write tests for. [18:38] A test that never fails for anyone is a waste of time. [18:38] For the past year or so, I have tried to get to 100% statement coverage for all my new projects. [18:38] It is sometimes a lot of work, but it gives me confidence when I'm making big changes: if tests pass, I am pretty sure the code still works as intended. [18:39] However, that is by no means guaranteed: it's easy enough to write tests at 100% coverage without actually testing every aspect of the code, so that even though all tests pass, the code fails when used for real. [18:39] That is unavoidable, but as you write more tests, you learn what things to test for. [18:39] As an example, since coverage.py on tests _statement_ coverage, it does not check that all parts of a conditional or expression get tested: [18:39] "if a or b or c" might get 100% statement coverage because a is true, but nothing is known about b and c. [18:39] They might even be undefined variables. [18:39] Then, when the code is run for real, you get an ugly exception. [18:39] In this tutorial I've shown how it is like to write tests before the code. [18:40] One of the results from this is that code written like this tends to be easier to test. [18:40] Adding tests for code that has already been written often requires jumping through more hoops to get decent test coverage. [18:40] also check out figleaf http://darcs.idyll.org/~t/projects/figleaf/doc/ [18:40] skips some coverage stuff in stdlib and such [18:40] I didn't know about figleaf, cool. thanks rick_h_ [18:41] I've also only touched the very basics of both unittest and automated testing in general. [18:41] For example, there are tools to make using coverage.py less work, and approaches to writing tests that make it easier to write good tests. [18:41]