Course code: ROL-2
Years with company:
Primary programming language:
Other programming languages:
Unit test harnesses:
Mocha/Chai for NodeJS, pytest and hypothesis for Python, only Googletest for C++
<script>alert("I like to break stuff")</script>;"
Test practice now:
When starting new feature: write Code with public interface, write gtest unittests for "happy path", write some more error/edge cases. If extending existing untested class: run executable on desktop and target.
ARMv7 single core with Yocto Linux
Visual Studio Code, remote ssh plugin, C++ plugin, Test Explorer UI plugin
We try to keep it in line with existing code, so it depends on what I'm working on. For new code, i mostly use clang-format and we have some naming conventions
Function too long:
Teamscale will complain about it. Without a tool, functions usually get too long when they do multiple things or have multiple depths of abstraction in one place
We actually started doing those in the past year. I submit a MR in gitlab and get valuable feedback from my domain-colleagues
Favorite thing about dev:
I like when software interacts with the real world: when something moves or does something.
Least favorite thing about dev:
I don't like to leave work when something is not working. And I hate how systems become complex over time due to added features.
I know I'm supposed to write tests first and I know I shouldn't write code that does not satisfy a test. I already tried to immplement some features in a tddish way. The tutorials I did usually worked with trivial examples like "int add_two(int)".
Why are you attending:
I hope to get some experience with tdd that goes further than the easy tutorials you find on the web. I'm not sure I'll use tdd in my day to day work but it can't hurt to have one more tool.