describe_syntax.py

# Requires Python 2.7 (class decorators and all)
#
# So my point in this is to be able to quickly generate behaviors for classes/features
# in software.
#
# I want to go from a line of
# @it("should ... ") statements, generated quickly in (OmniOutliner, some markdown
# document or whatever), and be able to wrap a Python TestCase around it quickly
#
# I also want to be able to extract the @it statements from the Python class
# and be able to do something like (or like rake shoulda::list), where all the
# @it blocks are printed out inside their describe blocks (so you can hand it off
# to business). This should not be all that hard, actually (I've done weird things
# like this with decorators before)


@describe("borrowing a book")
class LibraryBookTest(unittest.TestCase):
    @it("should keep track of when it was checked out by the current borrower")
    def test_timestamp_borrowed(self):
        # I don't care how you implement this method. Could be
        self.assertEquals( "today", book.timestamp() )
        
        # or could be with shoul dsl
        book.timestamp() |should| equal_to("today")
        
        #whatever.
        
    @it("should correctly calculate when the book should come back")
    def test_time_left_until_return(self):
        ....
    
    @it("should know if it's untimely or not")
    def test_untimely(self):
        ....

# ================================================================================================
# and yes, Python coders, I know you can use docstrings in a similar manner:

class LibraryBookTest(unittest.TestCase):
    def test_timestamp_borrowed(self):
        "should keep track of when it was checked out by the current borrower"
        self.assertEquals( "today", book.timestamp() )

# and you can do a similar trick to rake shoulda:list (iterate the unittest.TestCase subclasses,
# get all the instance variables of the test_* methods, get their docstrings, and bingo,
# but I don't see myself easily translating user requirements into:
#
# "should keep track of when it was checked out"
# "should know if it was untimely"
#
# Well, I could, but (a) it feels like something is missing when you read it as a sentence,
# and (b) ugh, now to port that into a def test_* I have to do a lot more text manipulation than
# I have to with a decorator approach ("return and you're ready to type def"). Which is no big deal
# but I think the sugar helps here.