关于Robot Framework、Fitnesse、Cucumber的简单对比

参考：

http://www.radekw.com/blog/2009/03/27/automation-frameworks/

http://robotframework.googlecode.com/svn/wiki/publications/Quality_Matters_Q1_2009_Collino.pdf

 

RecentlyI researched many testing frameworks in order to choose one to use at work. Ispent few days practically testing the following frameworks:

·        Robot Framework

·        FitNesse

·        Cucumber

 

Ichose Robot Framework. It is not perfect, but promising, extensible, and activelydeveloped by the open source community. The following features made me choosethis framework over others:

·        Keyword driven

·        Ability to use re-usablekeywords

·        Large collection of built-inkeywords

·        Test cases and suites areHTML documents

·        RobotIDE test case editor

·        Extendable in Python andJython

·        Reporting using HTML and XMLfiles

All this gives a solid base to extendand wrap around in order to create state-of-the art testing framework. Robot framework is easily installable. Examples anddocumentation are more than enough to get automation engineers and testersstarted. It requires some learning and getting used to (especially RobotIDE)but once grasped, creating test cases is easy. Additionally, new keywords can be simplyprogrammed in Python or Jython, or created with existing keywords (macros).Tests are started with a command line tool and can be very simply scheduledusing cron.

 

FitNesseframework is widely used and popular, but is not as extendable as robotframework. It’s a testing wiki. Test cases are created as tables in wikidocuments and are started by clicking a button on a page. The results show upimmediately, but there is no way to store them. Each test table must have acode fixture written in Java. Other languages can be used with a help of additionalFit servers. Being a wiki,FitNesse cannot be used for automatic and non-interactive testing. Automation can be achieved by usingcommand line runner or ant tasks.

 

Cucumberis a testing environment that allows testers to write tests in a a domain-specific languagebased on a spoken language. It’s behavior-driven, but all used sentencesmust be mapped in underlying programming language (Ruby by default). It’s easyto transcribe users stories into test cases, but it requires automation engineer to work with testerswriting every test case. On the other hand, it’s a very interesting andamazing way to write unittests.