I think the entire Arduino community would benefit tremendously from easier automated testing of 3rd party projects. One of the best things about Arduino is the huge number of libraries and hardware packages available but it can be a bit hit and miss.
Obviously if the ability to run unit-tests can be included without reducing the simplicity of the Arduino system I have no objection to the facility being there.
I have not come across libraries that simply don't work.
I suppose the test folder being in the root of the library is an existing convention outside the Arduino world?
I do, but I look at a ton of Arduino libraries and specifically look for bugs. I think if you use standard AVR boards and popular libraries you are much less likely to encounter bugs simply because so many people are using the library they become the unit tests.
The problem is there is this steep learning curve. In the time you spend initially getting a testing system set up you could have just manually done the tests several times over. Of course making the effort will pay off many times over in time but people often don't think about things that way.
Setting up the tests is a considerable chore when you start a new project, even if you are familiar with how to do it.
I suspect the problem that will bite you in the ass is the one that you never thought of building a test for.
You have not said if unit testing could allow someone to verify code for hardware they don't have. If that were possible I could see a lot of value.
In practice I am lazy.
I can certainly see the value of automated testing for a project that involves several programmers because it should eliminate the risk that programmerA inadvertantly breaks programmerB's code. But in that case you would build into the budget the cost of building the test system.
Yeah, it's especially nice for open source projects where you get random pull requests
Would it be possible for an author to run tests that verify compatibility with a board that he does not have?
So much of a microprocessor program depends on the physical world outside which cannot be tested using software.
Testing the physical world is irrelevant if you have the power to (via software) put the system into any state that the physical world might cause.
I don't agree [that Testing the physical world is irrelevant if you have the power to (via software) put the system into any state that the physical world might cause]It assumes that the physical world is always properly HIGH or LOW and that it properly changes state at the time when you expect it to. At the very least the microprocessor program should be able to deal with the situation when there is a fault in the physical world it is attached to.
I challenge you to post a piece of code that I can't properly unit test. I win either way -- either I can successfully test it with my library as-is, or I can use your example to improve arduino_ci.
I reckon you need a test which first of all determines if there is a switch bounce problem.
your previous comments on that topic just come off as bluster.