(Unit) test driven development with Robot Framework?
David
(unit) TDD rather than ATDD that it was designed for.
It would be most ideal if an organization can get all its teams to
converge on ATDD. But sometimes that doesn't work out, so you may end
up with developers doing TDD on their own, then QA tries to reuse the
TDD tests where possible, perhaps via custom framework or command line
execution, and/or QA does their own testing with RF or a custom QA
higher level test framework.
I was thinking using RF to drive TDD tests, and perhaps have
developers do that rather than use their native IDE or other
framework, and that would at least act as a bridge towards adopting
use of ATDD and RF. That's probably easier to do for Python based
applications, and maybe Java as well as those can be executed natively
(but likely with wrapper libraries). But I'm also thinking at a wider
scale with other platforms like .NET/C#, C/C++, Ruby, Perl, etc.
through use of remote library interfaces for driving TDD. Or for all
platforms, we can also utilize the old school method of command line
(or telnet/SSH) shell calls from RF (e.g the run keywords) to the TDD
frameworks to do same.
Anyone done something like this or thinking about doing this? Or am I
the only one thinking such unique ideas?
AndreasEK
completely seperate processes and deserve different tools :)
Andreas
Laurent Carbonnaux
I think ATDD and TDD, although sharing 3 letters and some ideas, are
completely seperate processes and deserve different tools :)
Andreas
--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To post to this group, send email to robotframe...@googlegroups.com.
To unsubscribe from this group, send email to robotframework-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/robotframework-users?hl=en.
Markus Gaertner
TDD is to drive the design of your code. It might have that "T" in its
name, but it represents that the unit tests are a means to reach a
flexible design.
ATDD on the other hand also has that "T" there, but it's a
requirements elicitation approach, that produces system-level tests as
a side-effect.
They truly have both their place on an Agile team, but while TDD helps
to write the code in the right way, ATDD helps you to focus on the
right function to program.
Best
Markus
> --
> You received this message because you are subscribed to the Google Groups "robotframework-users" group.
> To post to this group, send email to robotframe...@googlegroups.com.
> To unsubscribe from this group, send email to robotframework-u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotframework-users?hl=en.
>
>
--
Dipl.-Inform. Markus Gärtner
http://www.shino.de/blog
http://www.it-agile.de
Twitter: @mgaertne
Pekka Klärck
> I was just wondering if anyone has made use of RF for unit testing or
> (unit) TDD rather than ATDD that it was designed for.
This depends very much on how you define unit. If your unit is, for
example, a Java class your best bet is testing it with JUnit or some
other unit level testing tool. If your unit is something larger and
has an external interface, then using Robot or some other higher level
tool might be a good option. I normally refer only to the first kind
of testing with "unit testing" and use either "module testing" or
"integration testing" when talking about the latter.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Markus Gaertner
I can't agree with that. ATDD should not focus on any element in the
GUI at all. Your examples should be based upon a higher abstraction.
That abstraction should not deal with any elements in your GUI at all,
while still being focused on the underlying business goals. The
examples should be abstract, but not too abstract.
However, what I think you really might have meant is that you can base
your design based on the information you can gather by making the
tests pass in your test classes first. At that point you can inform
your design of the production code using the information gathered from
the automation that you used to make the specification by example
pass.
However, this is surely something I would not start with initially,
but could be a longer-term goal while adopting ATDD after all.
Best
Markus
--
David
> Hi Laurent,
>
> I can't agree with that. ATDD should not focus on any element in the
> GUI at all. Your examples should be based upon a higher abstraction.
> That abstraction should not deal with any elements in your GUI at all,
> while still being focused on the underlying business goals. The
> examples should be abstract, but not too abstract.
Interesting discussion I've brought up it seems. Markus, should I then
infer that you also mean to say there should be no Selenium automation
in unit tests even though Selenium's API would allow a developer to
incorporate calls to Selenium into unit test code via the xUnit tools?
Or perhaps that is OK, given the condition that the Selenium is
incorporated in higher level tests built on top of unit test tools/
frameworks, but not for the lowest level unit tests?
I ask that because my organization's developers are considering
incorporating Selenium in their .NET unit tests, though I don't know
what level of "unit" testing they consider that to be at.
David
commonalities between the TDD unit tests as well as ATDD tests. Take
for example API testing of "public" APIs. Developers will unit test
the API with API calls, but given a granular enough API, the ATDD
tests may also call the same APIs, perhaps with similar data as well.
In such a situation, why write up or maintain 2 separate test suites
that make same API calls and use similar data?
I may have missed certain options, but I see 3 possible paths in such
a scenario:
* the organization decides to take the developer-centric route. Re-use
and expand on the unit tests (framework/tool). QA will use those
expanded tests. Either QA or developers will do the expanding. In this
situation, testing will be driven by the xUnit tools or frameworks
built around it. If say QA wanted to use RF, then they'd have to
figure out a way to adapt the unit test tool/framework around RF or
the other way around. I assume in current industry practice, this is
the most likely route.
* organization adopts ATDD route, all tests driven by ATDD tool like
RF, including tests that may be considered at the unit level. I assume
in current industry practice, this is the least likely route.
* hybrid approach where both QA and developers try to find a common
ground, building out a common interface or API, where unit tests (via
unit test tools) and ATDD tools like RF use same API maximizing code
reuse and minimizing effort to port tests or maintain separate tests.
I assume this is also not a common route.
I am attempting the hybrid route at my organization, but we'll see how
that goes. It may be that I have to go the option of the first bullet
item. We use a scattered collection of tools and test frameworks (or
rather harnesses really), and I find RF to be a good candidate to
consolidating them all under a single framework with a single test
case or scripting format. Makes it easier to write integrated tests
that involve the multiple tools we have, and simplify our junior QA
members job from having to learn/use multiple test script formats. The
organization is working on new system configuration (and what I
believe to be a public) API, and the developers are going to assist QA
with test tool or framework for that. I figured, why not have that be
more tightly integrated with RF as a test library rather than end up
resorting to calling those APIs from developer's xUnit tool framework
over command line calls from RF wrapped into a custom user keyword
"library" (really a resource file). Though I could take the approach
of building my test library for QA that does the same thing, but
that's not an effective approach long term. I'm trying to establish a
middle-ware solution that is managed between development and QA, not
one or the other alone.
Laurent Carbonnaux
Pekka Klärck
> On Mar 22, 2:41 pm, AndreasEK <Andreas.Ebb...@gmx.de> wrote:
>> I think ATDD and TDD, although sharing 3 letters and some ideas, are
>> completely seperate processes and deserve different tools :)
>>
>
> commonalities between the TDD unit tests as well as ATDD tests. Take
> for example API testing of "public" APIs. Developers will unit test
> the API with API calls, but given a granular enough API, the ATDD
> tests may also call the same APIs, perhaps with similar data as well.
> In such a situation, why write up or maintain 2 separate test suites
> that make same API calls and use similar data?
This is a very good example of a case where both unit and acceptance
level tools can be used. It totally depends on the context which tools
work better or should both be used. Avoiding a larger set of
duplicated tests is a good idea nevertheless.
> I am attempting the hybrid route at my organization, but we'll see how
> that goes. It may be that I have to go the option of the first bullet
> item. We use a scattered collection of tools and test frameworks (or
> rather harnesses really), and I find RF to be a good candidate to
> consolidating them all under a single framework with a single test
> case or scripting format. Makes it easier to write integrated tests
> that involve the multiple tools we have, and simplify our junior QA
> members job from having to learn/use multiple test script formats.
Sound very good to me.
