[ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues

  • From: Asif Sardar <engr.asif.sardar@xxxxxxxxxxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Tue, 22 Apr 2014 14:49:44 +0300

Hello,

I wanted to write C-python module for robot framework test case. I have
some issues regarding it.

- I wanted to encapsulate the arduino function calls (pin_mode(),
digitalRead, digitalWrite etc) in the c-python module.
- Then I would use such module in actual test script to call appropriate
function for C-emulator functionality e.g.
   -> Set Pin High would call module.pinHigh(...)
   -> Check Pin High would call module.checkPin(...)
   -> Set Pin Low would call module.pinLow(...)
   -> Check Pin Low would call module.checkPin(...)
- I am confused with the emulator functions such as setup(), loop() and
main()

In the test cases, every arduino API function is called from the setup().
If I want to call them sequentially according to robot framework test case,
how would I do that? Any suggestions?

May I call arduino API functions directly in c-python module, neglecting
the setup(), loop() and main() ?

BR,
Asif Sardar.


On Tue, Apr 15, 2014 at 4:45 PM, Asif Sardar <
engr.asif.sardar@xxxxxxxxxxxxxx> wrote:

> Hi all,
>
> Please check the test repository and also wiki pages. Do you agree with
> the overall skeleton?
>
> BR,
> Asif.
>
>
> On Mon, Apr 14, 2014 at 4:48 PM, Teemu Hakala <temmi@xxxxxx> wrote:
>
>> On 14.4.2014, at 16:06, Pekka Nikander <pekka.nikander@xxxxxx> wrote:
>> > Great!  Now, how about writing a separate wiki page that contains the
>> instructions how to clone the repos locally and how to run the test cases?
>>  SO that e.g. Teemu and I can easily repeat the tests.  Of course, the
>> longer term goal is that all developers could run the test cases locally
>> each and every time before pushing something to the Runtime git repo.
>>
>> Instructions for the rest of us sounds like a very good idea. I’m very
>> interested in joining forces at creating the tests and making our test
>> coverage larger. I know pretty much nothing about Robot Framework, so
>> instructions relevant to how ELL-i uses it is very relevant.
>>
>> I made some issues in the [ELL-i-PyBot-Tests issue tracker][1] for some
>> basic tests to be made. Some of these are already on the way and may be
>> ready. The idea being that as not all of the [Arduino language
>> reference][2] needs be tested at first, we can keep track of what we think
>> be relevant at which stage and who is already working on what, to avoid
>> duplicate effort.
>>
>> Related to priorities of testing, I think that as the test suite starts
>> to be usable and familiar, we should pretty soon generate tests for some
>> [Arduino examples][3], most notably Blink and the like.
>>
>> Testing against real hardware is naturally very interesting. We might
>> want to take a look on [Sigrok][4] as a test automation hardware framework
>> as it supports our measurement hardwares of choice. I think that a good
>> intermediate solution is to define a set of tests that need human
>> interaction to run and gather the results, as not everyone will have their
>> [Rigols][5] and [Salaes][6].
>>
>>   [1]: https://github.com/Ell-i/ELL-i-PyBot-Tests/issues
>>   [2]: http://arduino.cc/en/Reference/HomePage
>>   [3]: http://arduino.cc/en/Tutorial/HomePage
>>   [4]: http://www.sigrok.org/wiki/Supported_hardware
>>   [5]: http://www.rigolna.com/products/digital-oscilloscopes/
>>   [6]: https://www.saleae.com/logic16/
>>
>>  - t
>>
>>
>
>
> --
>
>
>
> *With Best Regards,Asif Sardar.+358 43 8265795 <%2B358%2043%208265795>*
>



-- 



*With Best Regards,Asif Sardar.+358 43 8265795*

Other related posts: