GithubHelp home page GithubHelp logo

mmurdoch / arduinounit Goto Github PK

View Code? Open in Web Editor NEW
390.0 390.0 51.0 1.54 MB

ArduinoUnit is a unit testing framework for Arduino libraries

License: MIT License

Python 15.07% Shell 15.48% Perl 0.53% C 0.61% C++ 67.23% Makefile 1.06% Batchfile 0.01%

arduinounit's People

Contributors

crankyoldgit avatar freenerd avatar hanna-h avatar jnmacdnld avatar martinjansa avatar matthijskooijman avatar mattsoftware avatar mmurdoch avatar nicolaspanel avatar per1234 avatar soundanalogous avatar ssilverman avatar wmacevoy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

arduinounit's Issues

Order of tests

Hi,

more a question than a request:
Is there a way to specify the order of the Tests?

I have some tests, which needs to be run after another test.
Can I control the order in a way other than assigning numbers to the test names ?

Put literal test name strings into program memory

When a test is created using the test macro a literal string is generated which holds the test's name. Putting these generated literals into progmem would save precious SRAM. Since there is usually much less SRAM than progmem this seems to be a sensible enhancement.

Split tests in multiple files

Is there a way to split the tests in multiple files and have one central point to start them from?
It would make my testing code much cleaner.

Fails to compile for Arduino Due

On Due, PROGMEM is not available, so when compiling for Due, the compiler complains about undefined PROGMEM macros. As a workaround, these macros could be defined in ArduinoUnit.h:

// Workaround for Arduino Due
#if defined(__arm__) && !defined(PROGMEM)
#define PROGMEM
#define PSTR(s) s
#define memcpy_P(a, b, c) memcpy(a, b, c)
#define strlen_P(a) strlen(a)
#endif

Make TestSuite::add() private

TestSuite::add() is not intended to be used by unit testing sketches, yet it is a public member of TestSuite. This allows it to be called from the Test constructor (previously the SuiteAppender constructor). Better to make it private and make Test a friend class.

Wrong library.properties placement

Hi!
On https://create.arduino.cc/editor (the Arduino Web IDE) we include all the libraries in the Library Manager, your library is giving a warning for every single compilation, and many users have complained about it on our Forum.
WARNING: Category '' in library ArduinoUnit is not valid. Setting to 'Uncategorized'

This is due to the wrong placement of library.properties, you can find the guidelines on the right placement here https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ

We could really appreciate if you could move it and make a release, so that the updated version will be automatically displayed in the Library Manager.

Thanks a lot!

The examples show nothing in the serial monitor on my Arduino Micro

Hi all,

So I just started using ArduinoUnit, it seems promising!
Anyway: I just tried to run some of the given examples on my Arduino Micro and nothing was printed in the serial monitor. For a moment I scratched my head but then I realized that the While(!Serial); line is missing in the setup method. This line is required for the Arduino Micro/Leonardo because it doesn't have the 3000 ms delay at the startup like the other boards have.

So the setup method should be changed to:

void setup()
{
Serial.begin(9600);
while(!Serial); // Necessary for the Arduino Leonardo/Micro
}

to make the examples compatible with these two boards.
I would do it myself if I wasn't busy, I'm sorry for that :)

Cheers, Hanna

EDIT: I might have some time tonight. Will submit a pull request if no one else fixed it by then.

Assert equal doesn't work

I am trying to write some tests that I want it to fail but it appears I cannot get the tests to fail.
It passes even if I return an integer other than 0.

void MoveTest:: moveUpUnit() {
 for (int i=0; i<100; i++){
 box.slideUp(0);
 assertEqual(0, box.totalSlide());
 }
}

'AUnit' library: a rewrite of ArduinoUnit to support ESP8266 and reduce flash memory usage

Hi everyone,

I just uploaded a rewrite of ArduinoUnit called AUnit to:
https://github.com/bxparks/AUnit
It is almost a drop-in replacement for ArduinoUnit.

AUnit solves 2 pressing problems for me:

  • it works with ESP8266 (#68, #57, #55)
  • it has a far smaller flash memory footprint (#70). On the unit test referenced in #70, AUnit is 66% smaller, in other words, it's 1/3 the size of ArduinoUnit.

I would like to thank the ArduinoUnit contributors for creating such an easy to use framework. I was hesitant to create a new derivative work, but ArduinoUnit has not seen a release in over a year, and I wanted to make more rapid progress.

Let me know if you have any questions, I'm happy to answer them.

Problems creating unit test firmware using Arduino CMake

When I try to compile a project created with arduino cmake than I get compile errors.
The UnitTest.ino is realy simple and contains the first example.

In file included from /home/pedda/projects/arduino/UnitTest/UnitTest.ino:1:0:
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:110: error: two or more data types in declaration of ‘test_ok_instance’
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:8:7: note: in expansion of macro ‘test’
//=== START Forward: /home/pedda/projects/arduino/UnitTest/UnitTest.ino
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:165: error: declaration of ‘virtual void test_ok::once()’ outside of class is not definition [-fpermissive]
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:8:7: note: in expansion of macro ‘test’
//=== START Forward: /home/pedda/projects/arduino/UnitTest/UnitTest.ino
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:27: error: redefinition of ‘struct test_ok’
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:9:7: note: in expansion of macro ‘test’
void test(ok) ;
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:27: error: previous definition of ‘struct test_ok’
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:8:7: note: in expansion of macro ‘test’
//=== START Forward: /home/pedda/projects/arduino/UnitTest/UnitTest.ino
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:110: error: two or more data types in declaration of ‘test_ok_instance’
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:9:7: note: in expansion of macro ‘test’
void test(ok) ;
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:165: error: declaration of ‘virtual void test_ok::once()’ outside of class is not definition [-fpermissive]
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()
^
/home/pedda/projects/arduino/UnitTest/UnitTest_UnitTest.ino.cpp:9:7: note: in expansion of macro ‘test’
void test(ok) ;
^
/home/pedda/local/arduino/libraries/ArduinoUnit/ArduinoUnit.h:591:110: error: two or more data types in declaration of ‘test_bad_instance’
#define test(name) struct test_ ## name : TestOnce { test_ ## name() : TestOnce(F(#name)) {}; void once(); } test_ ## name ## instance; void test ## name :: once()

aso.

Arduino 2.0 gives progmem warnings on compilation

During compilation with the Arduino IDE version 1.0.3 the following warning is output a number of times (formatted here for clarity):

<install_dir>\arduino-1.0.3\libraries\ArduinoUnit/ArduinoUnit.h: In static 
    member function 
        'static bool Test::assertion(const __FlashStringHelper*, 
                                     uint16_t, 
                                     const __FlashStringHelper*, 
                                     const T&, 
                                     const __FlashStringHelper*, 
                                     bool (*)(const T&, const T&), 
                                     const __FlashStringHelper*, 
                                     const T&)':
<install_dir>\arduino-1.0.3\libraries\ArduinoUnit/ArduinoUnit.h:485: 
    warning: only initialized variables can be placed into program 
             memory area

Prevent duplication of side-effects in assertTrue and assertEquals

The condition argument to assertTrue and the expected and actual arguments to assertEquals are evaluated twice. If the actual values of these arguments have side effects then it may produce unintended results and hard to find bugs.

For further details see (for example): http://gcc.gnu.org/onlinedocs/cpp/Duplication-of-Side-Effects.html#Duplication-of-Side-Effects

Also see: http://jamesreubenknowles.com/on-chip-unit-testing-the-arduino-1580

Add additional useful assertions

For example: assertFalse, assertEquals for strings.

Ideally this will not increase the size of existing unit test sketches (i.e. those which don't use these assertions).

Commonalize FakeStream and FakeStreamBuffer

FakeStreamBuffer extends FakeStream but only provides the ability to add multiple bytes to the stream in a single function call. It would be nice to move this extra functionality down into FakeStream to simplify usage of the library (perhaps also deprecating FakeStreamBuffer?) We would also need to check the impact of doing this on the code size of sketches currently using FakeStream.

Add tolerance for double comparison

Doubles should really be compared using a tolerance, this is my current work around:

void assertClose(double a, double b, double tol = 0.01)
{
  assertTrue(abs(a - b) < tol);
}

Bug while comparing character arrays

The assertEqual() doesn't seem to work with character arrays. Following code fails the test:

test(string)
{
  char str1[32];
  char *str2="test1";
  strcpy(str1,str2);
  assertEqual((char*)str1,str2); // ok --  
} 

Error message is as follows:

Assertion failed: ((char*)str1=test1) == (str2=test1), file /tmp/build91e6c79303c447d1075081849910176c.tmp/sketch/tests/Utils_test.cpp, line 31.
Test string failed.
Test summary: 0 passed, 1 failed, and 0 skipped, out of 1 test(s).

I think, assertEqual is comparing pointer values (the addresses) instead of parsing the whole string and comparing character by character (which something like strcmp() would do). I have worked around it by using: assertEqual( strcmp(str1, str2), 0);

Fail to compile RFDuino

Failling to compile on RFDuino with error:

/Applications/Arduino_1.5.8.app/Contents/Resources/Java/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: address 0x20004374 of /var/folders/_w/wvsmn93n26q5v65gyt01x3p40000gn/T/build5167854416226854633.tmp/OpenBCI_Radio_Test.cpp.elf section `.bss' is not within region `ram'
/Applications/Arduino_1.5.8.app/Contents/Resources/Java/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: address 0x20004374 of /var/folders/_w/wvsmn93n26q5v65gyt01x3p40000gn/T/build5167854416226854633.tmp/OpenBCI_Radio_Test.cpp.elf section `.bss' is not within region `ram'
/Applications/Arduino_1.5.8.app/Contents/Resources/Java/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: address 0x20004374 of /var/folders/_w/wvsmn93n26q5v65gyt01x3p40000gn/T/build5167854416226854633.tmp/OpenBCI_Radio_Test.cpp.elf section `.bss' is not within region `ram'
collect2: error: ld returned 1 exit status
Error compiling.

This compiles without ArduinoUnit

Improve confusing test summary output

The standard summary output is confusing as it isn't clear at a glance which counts correspond to which result category (tests run, successful tests or failed tests). A successful test run produces output like this which at first seems to indicate 1 failed test...

Running test suite...
Tests run: 1 Successful: 1 Failed: 0

See also comment in this Firmata issue: firmata/arduino#41

Remove duplication of documentation (HTML and wiki)

The HTML documentation is not rendered by github and the wiki content is currently still on googlecode (http://code.google.com/p/arduinounit/ and http://code.google.com/p/arduinounit/w/list).

Possible approaches:

  • transfer googlecode wiki content to github wiki and delete HTML
  • convert HTML documentation to markdown so that it will display in github (don't transfer googlecode wiki)
  • transfer googlecode wiki content to github pages and delete HTML

Dealing with Arduino program size

Being super enthusiastic over ArduinoUnit I went crazy testing my program but now are faced with the program size limitation. I know had to cut down my test suite again to have everything fit on the chip again, but I'm afraid as my program grows I'll have to throw out the whole test suite for size reasons :(

Anyone knows a way to deal with this?

Test::assertion() consumes too much program (flash) memory

I used ArduinoUnit for one of my projects. Great library, easy to use, thank you.

Problem

I found that it consumes too much program (flash) memory. My unit test suite is about 1200 lines of code, contains 25 tests, using 300 assertEqual() and 8 assertFalse() statements. On an AVR, the sketch generates 49148 bytes of flash memory and 1039 of static memory. This is too big to fit inside an Arduino Nano (ATMega328P, 32kB flash). I ended up breaking the test suite into 6 separate sketches. (The overhead of the split required 3 sketches, and after that, it made more sense to break into 6 logical units, giving me more headroom to add more unit tests to each logical unit).

Having to run 6 sketches is time consuming and error prone. Large program size means that the flashing process takes a long time. Ideally, everything would fit inside a single sketch. I looked into why ArduinoUnit generates so much program memory code.

Diagnosis

The culprit is Test::assertion() and the problem seems to be a confluence of at least 4 things:

  1. The F() macro does not fold duplicate strings into a single string. So each usage of F(__FILE__), for example, will produce a separate string in flash memory, even if the __FILE__ string is the same.

  2. Test::assertion() uses __FlashStringHelper to receive strings, and the various #define macros wrap various strings into the F() macros. Each of those strings consumes separate flash memory, with no deduping.

  3. Test::assertion() is a templatized method. Therefore, each variation of the various assertXxx() macro will produce a new version of Test::assertion(). For example, I believe each of the following produces a new variation:

  • assertEqual(uint8_t, uint8_t)
  • assertEqual(uint8_t, uint16_t)
  • assertEqual(int8_t, int8_t)
  • assertEqual(int16_t, int16_t)
  • (and so on)

Common strings such as F("Assertion"), F("passed"), F("failed"), F("=="), F("( "), etc are all duplicated in flash memory.

  1. The assertOp() macro passes in the string of the arguments (F(#arg1) and F(#arg2)) into the Test::assertion() method. This allows the error message to be very helpful, because it contains the snippet of the actual source code of the parameters that was passed into the assertEqual() (and other) macros, for example:
Assertion failed: (5U=5) == (adjustableConfig.getRepeatPressInterval()=6), file AllTests.ino, line 805.

But this has a huge cost, because every one of those F(#arg1) and F(#arg2) strings takes up flash memory.

Solutions

I have a change which implements 3 solutions, each more aggressively building on the previous. Here are the numbers from my actual test suite that I mentioned above (25 unit tests, 308 asserts):

METHOD | AVR(flash) | AVR(static) | Teensy(flash) | Teensy(static) |         
-------+------------+-------------+---------------+----------------|         
     0 |      49148 |        1039 |         34336 |           2956 |         
     1 |      32360 |        1039 |         30008 |           2956 |         
     2 |      25474 |        1079 |         30008 |           2956 |         
     3 |      25290 |        1067 |         29856 |           2956 |    
  • Method 0: no change, the original code
  • Method 1: remove F(#arg1) and F(#arg2)
  • Method 2: all of Method 1, plus change F() strings into (const char*) (to allow deduping by the compiler)
  • Method 3: all of Method 2, plus reduce the diagnostic string produced by Test::assertion()

Method 1 gives the biggest gain, with the removal of the F(#arg1) and F(#arg2) strings, reducing the program memory size by 35% or about 16kB. The change is that the diagnostic message is now:

Assertion failed: (5) == (6), file AllTests.ino, line 805.

But this is still not enough for my test suite to fit into 32kB of an Arduino Nano.

Method 2 gives a further 14% savings, or about 7kB, for a total program memory savings of 49%. It produces the same diagnostic message as Method 1:

Assertion failed: (5) == (6), file AllTests.ino, line 805.

The cost is about 40 bytes of static memory (occupied by the short (const char*) strings, which are deduped by the compiler). This now fits inside a Nano.

Method 3 is more aggressive about shortening the diagnostic message in Test::assertion(), printing just:

Failed: (5) == (6), AllTests.ino #805.

The benefit is marginal, saving only 180 bytes more (or 0.7%), but it does reduce static memory usage by 12 bytes compared to Method 2.

For completeness, I tested my changes on the Teensy platform (ARM Cortex), and on the ARM processors, the flash memory savings is not as dramatic as the AVR platform. But I think the smaller we can make the program, the faster the edit/compile/test iteration cycle will be.

Proposal

I would like to see my Method 2 implemented, reducing the program memory size by almost 50%, at the cost of about 40 bytes of more static memory, and a slightly more terse diagnostic error message.

My preference would be to see the full Method 3 implemented, because I think the short diagnostic message is good enough. But the flash memory savings is marginal (less than 1%), so I can see the argument that the cost-benefit is not worth it.

Let me know if you would like to see a pull-request for the code that implements all 3 methods, and you can take look.

assertEqual rounding problems - caused by Arduino?

working with gyroscope and accelerometer trying to triangulate actual position.

So I was writing the following test in Arduino and I got to an issue.

double degreeToRad = PI / 180;

// A = cos θ * H
test(mf12t1) {
  double in1 = 60;
  double in2 = 2;
  double out = 1;
  double res = cos(in1 * degreeToRad) * in2;
  assertEqual(out, res);
}

The issue I came across was: The output I should have and the result from the formula were both 1.00, but the test failed anyway.
I started inspecting the error and figured out that res is actually something like 0.9999999046 due to rounding errors.

Because of this error I wrote a little piece of code to fix it for myself.

void assertAlmostEqual(double out, double res)
{
  double m = 1000.0;
  assertEqual(round(out * m) / m, round(res * m) / m);
}

I don't know if this is something; Arduino should fix, could be fixed in this library, or just has to be worked around.
But I thought, since I found the 'error' I could atleast mention it.

Run all tests from setup

I have attempted to use continuous integration during this project and therefore I need to run a series of unit tests as often as possible. ArduinoUnit has been a good framework for creating and running unittests, but I would like to be able to call them once from the end of setup.

The idea being that any time I run my code, I run the tests too. If they are run from loop they will remain in RAM and they are continuously checked if they have already run. This is not ideal, I would prefer that they are run in setup and then removed from RAM leaving more space for the project code to run.

The idea is to automate the process. At the moment I can either run the tests or my project code, but not both due to the heavy RAM usage of the project code.

Missing pgmspace.h

I am trying to use this library through platformio on my nodemcuv2. When I try to compile it I got the following error:

Compiling .pioenvs/nodemcuv2/lib/ArduinoUnit_ID946/ArduinoUnitUtility/FakeStreamBuffer.o
In file included from .piolibdeps/ArduinoUnit_ID946/src/ArduinoUnit.h:38:0,
from .piolibdeps/ArduinoUnit_ID946/src/ArduinoUnitUtility/ArduinoUnit.cpp:2:
Compiling .pioenvs/nodemcuv2/lib/ArduinoUnit_ID946/ArduinoUnitUtility/FreeMemory.o
.piolibdeps/ArduinoUnit_ID946/src/ArduinoUnitUtility/Compare.h:3:26: fatal error: avr/pgmspace.h: No such file or directory
#include <avr/pgmspace.h>
^
compilation terminated.
*** [.pioenvs/nodemcuv2/lib/ArduinoUnit_ID946/ArduinoUnitUtility/ArduinoUnit.o] Error 1

Change SerialReporter to report to any Print subclass

Since SerialReporter only calls methods defined on Print (and no longer calls Serial.begin() or any other Serial-specific methods) it could easily be extended to work with any subclass of Print e.g. by passing one to a new SerialReporter constructor (perhaps using Serial as a default). This would likely warrant a name-change (PrintReporter?) but doing so could be construed as a breaking change.

Running tests multiple times

I just got started with ArduinoUnit and it has been serving me pretty well so far. Well-thought out API and implementation, kudos!

However, after adding a few tests I'm running into a limitation: I want to run some or all tests multiple times, but with different options. It seems that ArduinoUnit pretty much makes this impossible without reimplementing some parts of the framework (e.g. parts of Test::run(), Test:resolve(), etc.).

I'm not really sure what the best way would be to support this, but it seemed good to discuss things here first. Usecases I'm thinking about:

  • Simply re-running all tests, but with different settings (e.g. set through global variables or members on the tests themselves). This is prevented because Test::run() removes them from the list, so afterwards there is no way to access the full list of tests (needing to manually iterate them) and there is no way to re-insert the tests into the list (root and insert() are private). Such a re-run should probably show another summary.
  • Running a selection of tests, possibly in a different order. This would require explicitly listing the tests. Currently you just call loop() and resolve() on them manually, but that does not show a nice summary (or shows it every time if the list is already empty).
  • Combining the previous two: Run specific tests first, then run all others.

Writing this, I think that some changes that would be needed would be to:

  • Add an option to keep tests in the list after they complete.
  • Add a resetAll() method or similar, that resets all tests (that are still in the list) to UNSETUP (a test that only wants to run setup once and not re-run it in reset can keep its own flag?). This method could also call a virtual reset() on each test for more control. The resetAll() method should also reset the counters.
  • Add a run(Test*) method that runs the loop for just that test (e.g. the core of the current Test::run() without the loop.
  • Add a showSummary() option to force the summary to be shown.
  • Add an option to prevent the summary from being run when all tests have run (so you can re-run some tests)

The last points wrt the summary are a bit more tricky - How does a test count when it is run twice, or not at all? What about tests there were started but not stopped?

How does this sound?

Add a way to prevent a failing test from running without having to comment it out or delete it

If you write a test (for example to expose a bug) then it would be useful to be able to commit that test but prevent it from running until the bug is fixed. This decouples the testing and fixing of a bug so that they can be done at different times and potentially by different people.

There is, of course, a potential downside with this in that when the bug is fixed you must remember to also ensure that the test now runs. All things considered though, this seems like a useful feature.

Put literal strings in SerialReporter into program memory

SerialReporter contains a number of literal strings which take up precious SRAM during default usage of the framework. Changing these to be stored in progmem would free up this space. This seems to be a good trade off as there is usually significantly more program memory than SRAM available.

Remove unnecessary pre-Arduino 1.0 compatibility

ArduinoUnit 2.x uses Arduino 1.0 features for storing strings in program memory therefore there is no sense in keeping the ArduinoCompatibility header which supports pre-Arduino 1.0 libraries.

Provide a sample project with continuous integration

Hello,

I think it could be a nice idea to provide a sample project (using arduinounit) with continuous integration to run automatically tests.
It should be in an other GitHub repository.
It could use Travis for downloading an Arduino compiler and emulator/simulator.
in .travis.yml arduinounit will be downloaded (as dependency of this sample-arduinounit-ci project)

You can find some links dealing with continuous integration and Arduino
https://github.com/adafruit/travis-ci-arduino
https://www.pololu.com/blog/654/continuous-testing-for-arduino-libraries-using-platformio-and-travis-ci
(they are using http://platformio.org/ )

Kind regards

PS : see also https://docs.travis-ci.com/user/integration/platformio/

https://github.com/platformio/platformio-remote-unit-testing-example

Remove use of malloc in test initialization

With a lot of tests the use of malloc() to dynamically allocate memory during initialization (in TestSuite::add()) causes bizarre failures due to stack/heap collision. Replacing the use of malloc() with static allocation (i.e. at compilation time) would make this much more obvious, preventing upload of the unit test sketch due to its large size.

fakestream

Is there a turorial or a doc for the fakestream class?

Unattended testing, light a led if all tests passed.

Hi!

I would like to test arduino shields as I make them.

I will use an arduino board with several unit tests in it, and I will connect shields and run tests on them.

arduino unit is just fine for the purpose.

I am not interested in the test log in most cases: when all the test pass, I just would like to light a green LED at the end of the testing if everything went OK.

I am following your API, but I cannot see a clear hook to check the results after all the tests have been run.

How would you implement it?

Thanks!

no matching function for asserts with strings

I am getting compile errors trying to work with assertEquals and assertNotEquals working with strings (actually character arrays).

Environment: Windows XP SP3, Java v7U25, Arduino IDE 1.0.5, ArduinoUnit 2.0 as of 2013/07/17

Reducing to simplified cases, starting from basic.ino, adding a couple of extra tests, this compiles:

test(demo)
{
  assertEqual("test", "test");
}

test(demo2)
{
  assertNotEqual("test", "test");
}

The following does not compile, giving:
basic.ino: In member function 'virtual void test_demo::once()':
basic:18: error: no matching function for call to 'test_demo::assertion(const _FlashStringHelper, int, const _FlashStringHelper, const char [5], const _FlashStringHelper, , const _FlashStringHelper, const char [6])'
basic.ino: In member function 'virtual void test_demo2::once()':
basic:23: error: no matching function for call to 'test_demo2::assertion(const _FlashStringHelper, int, const _FlashStringHelper, const char [5], const _FlashStringHelper, , const _FlashStringHelper, const char [6])'

test(demo)
{
  assertEqual("test", "test2");
}

test(demo2)
{
  assertNotEqual("test", "test2");
}

Can't create Strings in tests

test(string)
{
    // this fails
    String s = String("foo");
}

ArduinoUnit.h:284: error: 'class Test::String' is private

Is there a way to create Strings in tests?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.