Run Multiple Marathon Testcases In One Application
September 26th, 2010
# This goes to Fixtures/default.py
functional_test_dir = os.path.split(__file__)[0] + "/.."
# And this is TestCases/all_tests.py
#{{{ Marathon Fixture
from default import *
#}}} Marathon Fixture
import sys
import os
test_cases_dir = functional_test_dir + "/TestCases"
def load_test_cases(directory):
test_cases_directory = test_cases_dir + "/" + directory
sys.path.append(test_cases_directory)
dir_list = os.listdir(test_cases_directory)
test_case_files = filter(lambda fname:(fname.endswith(".py")), dir_list)
return map(lambda fname:fname.split('.')[0], test_case_files)
test_cases = load_test_cases("open_tests")
test_cases += load_test_cases("view_tests")
for test_case in test_cases:
exec "import %s" % test_case
def test():
for test_case in test_cases:
exec "%s.test()" % test_case
Lost + Found: Enthusiasm
September 18th, 2010
去了一趟澳大利亚。短短的几天时间里，见了Martin, Jim, Ola, Chris, Jez, Jason, Ines, Marina, Evan…一大堆牛人。在办公室跟一堆人聊天，跑到农场跟一堆人聊天，再跑到客户现场跟一堆人聊天…不知不觉间，连续出差一年中慢慢磨掉的热情，又回来了。
一个强大无匹的组织，开始面对内忧外患，于是他们想要改变。成千上万的人，把一个宏大的目标逐步分解成中期目标、短期目标和马上要做的事，然后开始一点点改变、一点点学习。除了所有的价值、意义，这本身就是一件如此有趣、如此令人好奇的事。而且，就在我面前，也有那样的成千上万人。看着一个个社会实验或成功或失败，这几乎可以纯粹是求知欲的问题。
回头看看，这一年学到了好多。尽管有很多无聊重复的事情，但是，还是学到了好多。再看得远一点，比起第一次去墨尔本时压根听不懂别人谈些什么，真是成长了不少呢。所以，还想学得更多，还想知道更多有趣的事。
（黄亮似乎也有同样的感受，所以 Test Everything 又回来了。只是，不知要到什么时候，我们才能不用这样隐晦的表述，把所有的故事原原本本地讲出来。）
贪婪与恐惧
September 3rd, 2010
有个小姑娘对我说：“我们真的很想用TDD的方式来开发，可是我们的基础太差了，我们真的能做到那样吗？”
人性的两大弱点：贪婪，和恐惧。亲眼看到了美好的可能性，于是迫不及待想要得到它，是为贪婪。一旦理想与现实抵牾，马上开始担心是否天堂遥不可及，在忧心忡忡中停止了前进，是为恐惧。
不要贪婪。静下心来把远景细化成一个个可以实施的细小改进，把一件件小事落实做好。不要恐惧。不要停下自我改善与帮助别人的步伐，在看不到山顶的时候也不要踯躅不前。每天向上走一点，也许到不了天堂，一定会比现在好很多。
（与WJ共勉）
作为管理工具的持续集成
September 3rd, 2010
有一个敏捷推行人，给她的团队设立了一个规则：每个函数不要超过30行。一开始，领导们都说，很好，很有道理。可是真的做起来，就发现遗留代码里有这样那样的特殊情况。紧跟着，开发人员也有了抱怨：我这里写32行又有什么损害呢？为什么一定要那么死板呢？于是，一个又一个的口子被打开。当然，你可以想象，有了越来越多的口子以后，“改善代码质量”也就成了纯理念──跟没有规则之前没什么区别。
我打算怎么做这件事呢？
- 把持续集成搭起来，只做编译。编译失败就红。红了就不能转测试，红了就必须马上修复，红了就是在阻塞整个团队的工作，红了就是最高优先级。让领导开始盯住持续集成。破坏构建就是和整个团队作对。
- 大家讨论一下，30行是不是一个合适的门限？如果不是，35行？40行？50行？行。我们就把门限定在50行。把静态检查放进持续集成。旧的代码我们既往不咎。就算现在有100个函数超过50行吧，没关系，我们容忍它。但是如果出现第101个长函数，就会让持续集成变红，要马上修复。
- 每次构建失败就是一个教育和学习的机会。一个人第一次写出长函数，我跟他一起重构；第二次写出长函数，我要看着他用我教的方法重构；第三次再写出长函数，那就要让领导来关心一下了。没有能力可以学，有了能力还破坏规则，说不过去了吧？
- 现在大家都学到怎么写更短小的函数了。偷偷把门限降低到45行试试？又多出来10个长函数。拉上几个开发者，我们来搞一次代码优化活动，把这10个长函数解决掉。于是大家又学到了更多的重构技巧。于是45行的门限变成了持续集成的要求。
- 两周搞一次代码优化学习会，降一次门限值。两个月以后，30行的标准就放在了持续集成里。如果有时间就去重构以前遗留的长函数，如果没时间就留着吧，至少大家已经不会写出新的长函数了。
先讲道理，再定规则，然后帮所有人提升能力以遵守规则，随着能力的提升逐渐拉高规则。30行的规则落实不下去？我就不信了。
把持续集成作为团队规则的自动、可视执行者，于是敏捷推行人就不必扮演那个凶恶的执法者，只需专心帮人排疑解难。持续集成把违规行为变成一个人与整个团队的对立，而不是一个人与另一个人的对立。
Migrating To A Decent SCM
September 1st, 2010
I know that lots of organizations are still using old-expensive-counterproductive configuration management systems (ClearCase, VSS, etc.). I understand the fear that prevents many of them from moving to a decent SCM (Subversion, Mercurial , etc.). I’ll try to tell a story about that kind of migration, which might alleviate the fear.
A huge company, with 40,000+ software developers, with 10+ years history using ClearCase, wants to migrate to Subversion, because of SVN’s encouragement to atomic commit and optimistic locking. The movement is still ongoing. Every single pace involves at least one delivery team, normally with 100+ programmers in it.
The movement must be as seamless as possible, because people are pushed to meet their next milestone. For a codebase sized over 4GB, we made the migration in a week:
- Monday
- Export the existing codebase and check it into SVN AS-IS—it’s time consuming so you have enough time for following items.
- Send mail to everyone to inform the migration plan, ask them to install SVN client if they haven’t.
- Make sure everyone can access new SVN repository.
- Tuesday
- Check out the codebase from SVN and build it, to make sure you are not breaking anything—that’s why you really should migrate AFTER you have a decent build script.
- Compose a shell script to synchronize from ClearCase local view to SVN working copy. Synchronize frequently and build every time.
- Wednesday
- Clean the codebase: legacy repositories often have lots of garbage (temp files, compiled binaries, etc.) checked in, it’s now a chance to do some clearance, delete and ignore them from SCM. Just don’t break the build.
- Install continuous integration instance for the codebase in SVN.
- Synchronize and build frequently. Ask people to fix build if it breaks.
- Thursday
- Send mail to everyone, ask them to commit any modifications by the end of day, and tell them “there’s an SVN training tomorrow morning”.
- Keep doing clearance. Synchronize and build frequently.
- Friday
- Disable write-access to ClearCase.
- Training: Configuration Management & SVN. People need to understand some SCM principles to make a better use of SVN—at least not to mess up the codebase with garbage again.
- At the same time, synchronize a last time, build, check in.
- Package your working copy and upload it to a shared directory: it’s much faster to copy and unzip, than checking out from the repository. Mail everyone about how to get a working copy and make first commit.
- Publish your CI to the team. It’s now the team’s CI.
That’s it. Now your team is on SVN.
