As a warm up to our Embedded Day Oslo (http://www.code-conf.com/embedded-osl-2017/) we will have an evening of fun talks to get us in the spirit!
Test-Driven Development guided by Zombies! (James Grenning)
James Grenning - co-author of the Agile Manifesto and Author of TDD for Embedded C
Have you had a hard time figuring out where to start with Test-Driven Development. What if ZOMBIES could help you build code that does exactly what you think it is supposed to do? What if ZOMBIES helped you build a test harness that can keep your code clean and behaving as expected for a long and useful life?ZOMBIES can help!I'm not talking about a legion of undead or virus stricken. ZOMBIES is an acronym that helps you, the engineer, decide where to start, what test to write next and make sure that, to the best of your ability, you do not forget critical tests and production code behaviors. We'll go through the though process and steps with a detailed code example.
• ZOMBIES' foundation is in the Zero-One-Many (ZOM) programming pattern
• To provide additional guidance behind ZOM, the programmer needs to constantly pay attention to
• Exceptional situationswhile defining
• Simple test Scenarios
Creating side-projects for fun and profit! (Leif Ove Finnerud)
Wanna have fun? Creating an embedded product on your spare time can be a frustrating and time-consuming journey, but more than anything else, it is fun!
A small-scale, spare time project typically involves all the cool stuff you wish you were better at, like schematics, coding, financing your hobby without upsetting the wife, mechanical design, reflow soldering in your kitchen, sourcing parts, sales, poor man’s pick&place, automating web server configuration, PCB layout, security, environmental testing, etc, etc.
Leif will take us through how he created badevann.no (http://badevann.no/) and several generations of wireless ocean temperature sensors on his spare time. Maybe his story will inspire you to finally do something about your own product ideas?
To quote Jack Ganssle in an interview with embedded.fm (http://embedded.fm/) in 2015: «A prototype is only 10% of a product»
Catch Dancing Ponies: try Approval Testing (Emily Bache)
The Acceptance Test stage of a Continuous Delivery pipeline is often a struggle for teams who have only previously worked with unit tests. It is much more challenging to design automated tests that exercise a whole feature, using an external API. In my experience, unit testing tools and approaches often lead to a lot of test code, that doesn’t necessarily find many issues. I heard about one CD team where someone had put dancing ponies on one of their pages as a joke. They intended it only to be visible to system administrators, and, perhaps unsurprisingly, none of the acceptance tests checked there were no dancing ponies! Unfortunately the customers weren’t too impressed when they subsequently saw them on the live site…
What I mean is, the best approach for a unit test - assert only specific things - may not be the best strategy for an acceptance test. If you forget to explicitly check something, tests can pass and bugs, (or ponies!) can slip through unnoticed.
In Approval testing, you generally take an opposite standpoint - by default everything is interesting, and everything will be checked. When a test designer automates an acceptance test scenario, they will ‘Approve’ the whole program output, or explicitly decide some parts to filter out first. Any future deviation from the approved output will be marked as a test failure. The test designer’s responsibility is therefore reversed - all output is interesting unless they say otherwise. This kind of a test can find bugs no-one anticipated when it was written, and in my experience, this happens reasonably often. Perhaps not actual dancing ponies, but still.