StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>We have been using Robot Framework at my place of work for several over a year now with moderate success. Like the poster, we also do C++ work. We took some time to evaluate Robot against Fitnesse/Slim and, at the time, both solutions were good, but the deciding factors were (as of ~2009):</p> <ul> <li>It was clearer how Robot and its reports would scale to large projects</li> <li>It wasn't obvious how to version control Fitnesse artifacts</li> </ul> <p>From a technical perspective, we have been using <a href="http://www.swig.org/" rel="nofollow">SWIG</a> to bridge between Robot and C++. We wrap our test fixtures in SWIG and link it with the production code under test - giving us a python module that can be imported by Robot. </p> <p>We use the .txt format for Robot input almost exclusively - we've found that this version controls better, it's easier to read, and we simply weren't using the advanced features of HTML (which is where we started). In addition, we are using the <a href="http://robotframework.org/robotframework/2.9/RobotFrameworkUserGuide.html#embedding-arguments-into-keyword-name" rel="nofollow">"BDD Style"</a> Robot syntax as well. We use GoogleMock with some wrappers to help us set expectations which are checked during the teardown of each Robot test.</p> <p>As far as organizing the tests, we have settled on the following approach (with inspiration from <a href="http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf" rel="nofollow">Dale Emery's approach given here</a>):</p> <ul> <li>Major functional hierarchy is represented by a folder structure.</li> <li>A feature-ish sized thing is described in a Robot test file name.</li> <li>A description of each part of that feature is used at the Robot test case name.</li> <li>An example is given as the steps in the test case.</li> <li>The example text is broken down into steps using Robot "keywords".</li> <li>The test fixture drives the production code.</li> </ul> <p>For example, a phone might have something like this:</p> <pre><code>// PhoneProject/MakingCalls/DialAPhoneNumber.txt *** Test Case *** A user can dial a US number with an area code, up to 10 digits Given a phone without any numbers dialed Expect the attempted phone number to be 123-456-7890 When a user enters the numbers 1234567890 // A separate MakingCallsKeywords.txt or something similar *** Keyword *** Given a phone without any numbers dialed CreateNewDialer Expect the attempted phone number to be ${phoneNumber} ExpectDialedNumber ${phoneNumber} When a user enters the numbers ${numbersEntered} DialNumbers ${numbersEntered} // MakingCallsFixture.cpp (which gets wrapped by SWIG) std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered) { ... Drive production code ... } // CreateNewDialer, ExpectDialedNumber also go here </code></pre> <p>We would then pair this up with unit tests that cover the corner conditions (e.g. ensure no more than 10 digits are allowed) - or maybe that would be another acceptance test (executable spec) depending on who is reading the tests and their familiarity with the domain.</p> <p>We create a draft of these specs and review with domain experts and the team prior to beginning work. This has helped flush out a number of misunderstandings early on. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload