The current example[0] uses assertTrue(element in self.seq) but it would be better to use assertIn instead.  The whole example could be changed to something simpler that uses only the assertTrue/assertEqual/assertRaises methods correctly, e.g.:

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

[0]: http://docs.python.org/py3k/library/unittest.html#basic-example

LGTM.

I tried to implement the improvements suggested by Ezio Melotti and updated the documentation accordingly.

I would be +1 if the basic example also highlights setUp and tearDown methods. Those are useful ones for a new comer to know via an example snippet and not just with explanation.

I think there’s value in accepting the current patch as really basic example, and then see if the section about setting up and tearing down also has a very simple example.

I'll be updating this example shortly, but it is intentional that it include only assertEqual, assertTrue, and assertRaises.  Those three are the minimum necessary to get up and running (which is the whole point of the BASIC example).

The patch includes only assertEqual, assertTrue, and assertRaises and, except a s/functions/methods/ in the first line, looks good to me.

Ezio, please leave this one for me.

I think `self.assertRaises(TypeError, s.split, 2)` looks simpler. In any case two examples for assertRaises needed, simple inlined and more complicated use as context manager.

Given that this is a basic example, it's not necessary to introduce both the forms of assertRaises.
I personally find the context manager form more readable, and I prefer it to the regular one even if it takes two lines instead of one.

FWIW, I'm going to test some other module (math or somesuch) rather than the built-in string methods.  The normal use of unittest is to import both the unittest module and the module under test.  I want to show that pattern (which is somewhat different from doctests where the tests are typically in the same file as the code being tested).

Raymond, in the meanwhile can the proposed patch be applied?
I don't think it's necessary to show that you need to import a module in order to test its functions.  Using modules also has the disadvantage that people might not know what result to expect if they are not familiar with the functions of that module (e.g. the only functions that return True/False in the math module seem to be isfinite/isnan/isinf), whereas everyone should know basic string methods.

Yes, go ahead an apply this patch.

New changeset 4a2a5fddbab3 by Ezio Melotti in branch '2.7':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/4a2a5fddbab3

New changeset 010e33b37feb by Ezio Melotti in branch '3.4':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/010e33b37feb

New changeset d6791e4026f1 by Ezio Melotti in branch 'default':
#11468: merge with 3.4.
https://hg.python.org/cpython/rev/d6791e4026f1

I tweaked the wording a bit, added a link to the section about setUp/tearDown, and applied it on all the 3 branches.
Thanks for the patch Florian!