Course code: BIRD-1
Years with company:
Primary programming language:
Other programming languages:
Unit test harnesses:
GTest, JUnit, pyUnit, nUnit
I like to play music (piano and guitar) in my spare time.
Test practice now:
Haphazardly. I start with unit testing, but once the work of mocking becomes large, time pressure generally puts the focus on writing more features rather than mocks.
At the intermediate level, we do some integration testing. For example, test that all endpoints of our embedded webserver respond as expected, with the hardware mocked out.
At the final level, we test that the UI behaves as expected and that the device behaves as expected, but often overlook testing error conditions or trying to cause error conditions.
Currently it is an Arria 10 SoC, which is serving up a webpage for user control.
VS Code, Visual Studio, PyCharm
We do not have a coding standard which is enforced.
Function too long:
When it tries to do more than one thing.
Generally, the the reviewers know what the code is supposed to accomplish and the primary developer explains how the code achieves the goal.
Favorite thing about dev:
I building a system to accomplish a task and partitioning the complexity into realizable components.
Least favorite thing about dev:
I know that the idea is to define the tests before writing the code. However, I've found that very difficult to do in practice.
Why are you attending:
I have two major questions that I would like practical answers to: 1. In the embedded world what are good approaches to mocking out hardware.
2. How do you minimize the impact of changing requirements while using TDD.