| Write code. Write unit tests for it. Fix broken tests. Repeat. |
Head Unit in car running the latest Android. |
Android Studio, VS Code |
Checking for mistakes in logic, non-optimized code, making sure business requirements are satisfied |
1-5 minutes |
60 |
30 |
10 |
Show
|
| Gtest, Manual Test |
Arm Embedded |
Source Insight, Teraterm, MobaXterm, Vi, LTTNG, Trace Compass, etc |
Standard Code review Checklist. Check for any Dynamic Memory allocation and its life cycle.
|
31-60 seconds |
3.5 |
3 |
3.5 |
Show
|
| Writing JUnit test code.
Functional testing with reference devices. |
Android |
- |
- |
1-5 minutes |
30% |
30% |
40% |
Show
|
| Unit Testing |
Android |
GTest, Gerrit, Eclipse |
Effective mostly |
11-30 seconds |
2 |
2 |
2 |
Show
|
| unit test and functional test |
Android |
Android Studio, VS code |
Done on Gerrit |
5-30 minutes |
5 |
3 |
2 |
Show
|
| Writing Unit test, and executing those. |
ARM, X86 |
vim, Android Studio |
NA |
1-5 minutes |
40 |
30 |
30 |
Show
|
| By Writing a test Application to test the functionality |
Mostly Head units |
Eclipse. Visual Studio Code. |
NA |
1-5 minutes |
60 |
20 |
20 |
Show
|
| Majorly Manual testing . Small libraries using gtest |
Linux, QNX,Android |
IDEs |
2 level reviews. 1 peer review and 1 architectural review. |
5-30 minutes |
60 |
20 |
20 |
Show
|
| Android test frameworks |
IVI Headunit. QC and Samsung ARM processor |
Visual Studio Code |
Use Gerrit for code reviews |
1-5 minutes |
10 |
5 |
5 |
Show
|
| the team uses unit tests by using a test framework |
embedded target for incar usage |
different C compilers for IO Controller (AUTOSAR) and Wakeup Controller |
Peer review to check the code before submit |
30-60 minutes |
0 |
0 |
0 |
Show
|
| GTest |
Embedded System Linux QNX |
Momentics, Eclipse, Vim |
Gerrit |
5-30 minutes |
30 |
30 |
40 |
Show
|
| Use some unit tests. But not cover full code. |
Linux, windows and QNX |
visual studio |
we have an official code review tool |
5-30 minutes |
40 |
30 |
30 |
Show
|
| First manual testing on the Hardware then write the unit test cases to mock and test different scenarios |
Infotainment running on Android. I work in middle layer, interacting with HMI & Android frameworks. |
Android IDE |
Code reviews are done thoroughly, from identifying the various use-cases and errors, to redesigning |
5-30 minutes |
50 |
30 |
20 |
Show
|
| google test |
Android Automotive |
Linux |
Git, gerrit |
5-30 minutes |
8 |
4 |
8 |
Show
|
| google test |
Android Automotive |
Linux |
Git, gerrit |
5-30 minutes |
8 |
4 |
8 |
Show
|
| gtest |
customer Hardware |
Gtest and gmock |
We use predefined checklist |
5-30 minutes |
5 |
5 |
5 |
Show
|
| unit tests, manual testing during development |
ubuntu 20.04 |
visual studio code, gcc, |
at least other developers are reviewing my code with every change request |
5-30 minutes |
40 |
40 |
20 |
Show
|
| I'm writing unit tests and I am doing manual tests to check, if algorithm is sufficiently accurate |
Ubuntu |
Git, cmake, Visual code |
To merge code required is positive review from one software engineer and one senior engineer. |
5-30 minutes |
50 |
25 |
25 |
Show
|
| Run it in visual studio |
No comments |
Visual sudio, Code blocks |
Not much review comments since i have only done customizations so far |
31-60 seconds |
40 |
40 |
20 |
Show
|
| The last large-ish project I wrote, I used Expecto |
dotnet core (multi-platform) |
VS Code, VS Studio, Notepad, Various web IDEs |
Everything from inspection to mobbing |
Under 10 seconds |
80 |
0 |
20 |
Show
|
| In my current project, we do not have a unit testing setup yet so the testing is done by executing use cases and looking at the output and logs to determine if everything is working as expected. |
We execute our binary on the Ford PCBA Board |
We mainly use git as our version control.
Gerrit for code review. |
Code reviews are done on gerrit. +1 and +2 are needed for merging changes. +2 rights are limited. |
5-30 minutes |
40% |
30% |
30% |
Show
|
| Do Unit Test with Google Test |
DSP SOC platform |
Visual Studio, bitbucket, NXP MCU IDE, Hifi4 Xtensa Xplorer IDE |
Review with bitbucket system |
30-60 minutes |
3 |
3 |
3 |
Show
|
| mostly tdd. I rarely write the source before writing a test first. |
mostly arm cortex ( stm32 series ). I do use an arduino with the atmega328 or mega2560 for PoC |
mostly arm gcc with libopencm3, sublime text, gdb, platformio |
none |
1-5 minutes |
30-35 |
15 |
40 |
Show
|
| With hardware using debugger. |
Mostly STM32. |
STM32CubeIDE |
I am not reviewing codes most of the time. |
31-60 seconds |
40 |
10 |
50 |
Show
|
| CppuTest and specflow |
various, typically stm32 these days |
Current favorite is vscode |
Depends on client, preference is frequent small reviews |
Under 10 seconds |
4 |
5 |
1 |
Show
|
| Using either our test scripts on our emulators or through stepping through the debugger to see our values are what we expect them to be (which has been a painful way to test) |
We use an ARC based processor which has 2 cores and a finicky debugger. It uses a ccac compiler |
Jenkins, parasoft, Metaware (eclipse based IDE) |
I've only been here for 7-8 months. Haven't had a code review yet- I know it happens though. |
5-30 minutes |
2 |
5 |
3 |
Show
|
| Unit test using CMock and Unity |
ARM Cortex-M3 and Cortex-M4 |
IAR Embedded Workbench |
For my current project, there isn't a set code review guidelines. |
31-60 seconds |
40 |
30 |
30 |
Show
|
| Unit & Simulated Verification Testing |
Cortex-M3 |
Sublime Text
Saleae Logic Analyzer
DS-5 Debugger w/Trace |
Paper and Functional testing based |
31-60 seconds |
25 |
50 |
25 |
Show
|
| Unit testing, Manual and Automated verification testing, low level integration testing. |
Implantable cardiac devices. |
Eclipse, IAR for ARM, SVN, CVS, Git. |
Typical formatting rules. Keep code simple/readable to limit risk. |
1-5 minutes |
50 |
30 |
20 |
Show
|
| Log, debugging message, debugger |
Embedded devices |
Dedicated EDA tools |
Multiple team member review |
5-30 minutes |
55 |
30 |
15 |
Show
|
| I use debug trace statements to follow the execution path and log variables. I use a tool to send messages to exercise the paths/features. |
ARM M3/M4 MCUs controlling some discretes & peripherals (Bluetooth, USB, I2C, SPI). Soft real-time. |
Keil MDK, Segger System View, VS Code, Coverity static analysis, MS TFS, custom tools. |
Independently performed by one or two individuals, usually by diffing. |
31-60 seconds |
55 |
20 |
25 |
Show
|
| I use debug trace statements to follow the execution path and, when needed, log variable values. I use a tool to send messages to exercise the paths/features I'm interested in. Such testing is not readily repeatable. |
ARM M3/M4 MCUs controlling some discretes & peripherals (Bluetooth, USB, I2C, SPI). Soft real-time. |
Keil MDK, Segger System View, VS Code, Coverity static analysis, MS TFS, custom tools. |
Independently performed by one or two individuals, usually by diffing versions. |
31-60 seconds |
55 |
20 |
25 |
Show
|
| unit tests and manual tests |
AWS integration or Here location platform integration |
Intellij IDE
Sublime Text
Gitlab |
requires someone else to verify every change but it can be cheated by +2ing it yourself |
11-30 seconds |
30 |
50 |
20 |
Show
|
| Using Development tests which execute individual use cases. |
It is an embedded ARM based system. |
Keil Compiler, Segger tools. |
We use peer reviews. |
1-5 minutes |
50 |
25 |
25 |
Show
|
| set of requirements tests |
iPadOS, Windows, RTOS, bare-metal |
XCode, Visual Studio, Keil uVision, PyCharm |
formal, mandated by FDA rules |
31-60 seconds |
15 |
10 |
10 |
Show
|
| unit and integration |
custom |
arm |
manual |
31-60 seconds |
60 |
20 |
20 |
Show
|
| Unit testing with cpp-test and a lot of systems testing with Python integration and hardware etc |
Device for preparing sample for DNA sequencing |
VSCode, Cypress, Xilinx ISE/Vivado |
Merge reviews are monitored as and when they come in and we do our best to keep things tidy |
5-30 minutes |
3 |
2 |
5 |
Show
|
| ceedling - system test |
space microcntroller -vorago |
keil |
reduced |
1-5 minutes |
10 |
10 |
10 |
Show
|
| I don't. |
Target system? If you mean what OS I use, then Windows and Linux, but Linux for developing. |
VS Code mainly. |
I haven't really had a proper code review with my company yet. |
1-5 minutes |
4 |
2 |
4 |
Show
|
| Testing team |
STM32F405
32 bit CortexM4F |
GCC
Notepad++ |
Once per month. 5 members (entire team). We go through an interesting a complex file. |
11-30 seconds |
5 |
3 |
2 |
Show
|
| Most of the time manually |
System in Package device which include ARM application processor and GPS receiver |
GCC |
Internal agreements for reviews. Fallowing google & gitlab style/recommendations |
1-5 minutes |
50 |
40 |
10 |
Show
|
| Using CppUtest framework. Tests are built and ran in Docker environment running on Linux/Windows machines. |
Cortex-M4 SOC with integrated GNSS receiver. |
VSCode, CMake, gcc, gdb, git, clang-format |
Every change goes into development using pull request which are reviewed by at least 1 developer. |
31-60 seconds |
40 |
30 |
30 |
Show
|
| With CppUTest |
Arm core, LTE modem and GNSS module |
gcc-arm-none-eabi toolchain, cmake + make build system, docker container for build env, vscode |
Code reviews are done before merge requests |
Under 10 seconds |
60 |
30 |
10 |
Show
|
| Mostly manual integration tests
- Develop new feature
- Compile and deploy to target
- Exercise system to observe intended behaviour
Very limited automated integration/unit testing |
- Work on multi-device embedded systems with real-time constraints
- Medium-sized legacy codebase |
- Emacs for text editing
- GCC-like tool chains
- Git
- Jira/Confluence/Bitbucket
- Jenkins |
Engage appropriate domain SMEs (1-5 people)
Turn-around (1 day - months)
Diff 1-5000 lines |
1-5 minutes |
40% |
<10% |
>50% |
Show
|
| I have only been at my company for 4 months. I have heard that the company is starting to use Google unit tests. |
ARM Cortex M4 (Kinetis) and also SOC boards (with ARM and FPGA) |
VSC code for IDE
make, gcc
gdb
Jira, bit bucket
Git
-on Linux laptops |
We use bit bucket to generate PRs and it is then reviewed by 1-2 people. |
1-5 minutes |
50 |
20 |
30 |
Show
|
| Unit test, manual test, static analysis |
Embedded vision system with mechanical components and real time control |
Emacs |
Bitbucket pull request |
11-30 seconds |
40 |
10 |
50 |
Show
|
| Not in a systematic way. Pass in extreme values to the function and verify I get what I expect. I step through the logic with each expected value (usually by "hand") and then work through it to verify it's correct. |
Primarily 32 bit ARM Cortex-M MCUs |
IAR |
Mostly informal - with a few other software devs reviewing the code and walking through it. |
1-5 minutes |
40% |
20% |
40% |
Show
|
| The team I am affiliated with uses parasoft but I've never used it. |
4 interconnected arm based micro processors. Each one has a forth interpreter exposed via a UART. |
IAR, gcc, clang, make, Jenkins |
Peer review per code change. |
30-60 minutes |
10 |
50 |
40 |
Show
|
| Integration and Functional/System Tests. |
stm32F429 with motors, pumps, and various peripherals. |
Keil MDK
Segger JLink
VS Code |
We are developing software development workflows which are now including Code Reviews with associated Git Pull Requests. |
1-5 minutes |
4 |
2 |
4 |
Show
|
| Personal projects: largely TDD
Professional projects: a bit of TDD |
Current: Multi Arduinos used on a NASA project for photovoltaic R&D, to improve power output for the Lunar Gateway project. Simulated sun system for testing PV's on earth, plus balloons to 120,000 ft to calibrate things in space. |
Eclipse, Arduino IDE, |
Rare. Usually when there are questions. Or at end of completion of a new feature area. |
11-30 seconds |
30 |
30 |
40 |
Show
|
| unit test, integration test |
Embedded |
Visual Code |
Thorough code reviews |
1-5 minutes |
50 |
35 |
15 |
Show
|
| Our testing is done manually. Manually writing test cases for functions and modules. |
Arm Cortex-M4, mainly STM32F4s |
Keil uVision MDK, Parasoft C/C++ Test |
Reviews are done during pull requests of our git-based repository. |
30-60 minutes |
30 |
40 |
30 |
Show
|
| C production code is tested using CUnit. We chose this library because it was very easy to compile with our custom toolchain and does not require an OS.
C++ production code is tested with CxxTest. We chose this library because the python script that auto generates the test harness is easy to configure for use without an OS.
All unit tests are run on the target system. This allows us to unit test things like GPIO assertions and interrupt handlers. |
SoC with a custom MIPS processor. |
Custom C and C++ compiler and toolchain (gcc patch).
CMake for defining the build rules, which generate Makefiles we use for building.
CUnit for C unit testing.
CxxTest for C++ unit testing.
Emacs |
Usually involve 4-6 reviewers, each reviewer spends 2 weeks annotating the code. We use a custom tool that allows reviewers to collaborate and make in-line annotations without modifying the code. |
1-5 minutes |
50% |
40% |
10% |
Show
|
| unity test harness running on simulator,
manual with debugger |
Microchip dsPIC33, ST stm32f4, multiprocessor safety-critical system |
MPLAB X, Keil uVision, Visual Studio Code, batch files |
Not optimal |
11-30 seconds |
33 |
33 |
33 |
Show
|
| Testing the end product directly, with a human. |
Various avionics systems, some of which are ARM microcontrollers, and some which are x86 embedded linux systems. |
VSCode, Various IDEs for different microcontrollers, svn, git |
Using crucible currently, but not very experienced with it |
5-30 minutes |
50 |
20 |
30 |
Show
|
| I generate a test plan independent of the SW project based on user requirements/use-cases and then manually create a test document to run the SW through the tests |
x86/ARM |
Visual Studio, Eclipse, Android Studio |
In my prior position as a Sales Engineer I lacked access to really experienced mentors for code reviews. I'm hoping to get a lot of feedback from code reviews in my new role in Engineering. |
1-5 minutes |
60% |
30% |
10% |
Show
|
| Test using the product and multiple different inputs to see if I get the desired result. |
Zebra mobile printers running on c/c++ |
QNX Momentics |
I call another developer that is an SME in that area and show them my changes. They ask me to change something or give their approval then and there. |
1-5 minutes |
20 |
40 |
40 |
Show
|
| The most important are functional developer tests. Automated testing is carried out in development with cmocka.
Our system test writes much more extensive automated tests, mostly in Python. |
Our target systems are 2G / 3G / 4G radio modules. |
Qualcomm Build Environment, Qualcomm tools like QPST, QXDM and many more. |
Are done together with colleagues. |
5-30 minutes |
25% |
25% |
25% |
Show
|
| In most cases: pepper with Debugs, run & check, remove debugs |
Embedded multicore systems |
editor, compiler, debugger |
In most cases I am involved in advance and know the changes. |
5-30 minutes |
50 |
25 |
25 |
Show
|
| 1) compiler as static code analyzer
2) cpp check as static code analyzer
3) source code review
4) manual tests
5) cmocka on a daily base via jenkins
6) system test cases on a daily base via jenkins |
Embedded system with multiple cores, typically based on ARM 32/64 bit. |
Source Insight
Beyond Compare
CPP Check |
Very useful.
The skill is to invite people which are able to give useful feedback. |
5-30 minutes |
20 |
60 |
20 |
Show
|
| Jenkins CI
Debugger
Logging |
Embedded ARM |
Some |
Gitlab |
5-30 minutes |
? |
? |
? |
Show
|
| Testsuites provided by OS manufacturer (Windows kernel drivers), self written test suites (Android and Linux drivers), manually (everything). |
X86 systems with Windows or Linux, Android systems. No embedded systems! |
Many, depends on the kind and target of my current task. |
? |
1-5 minutes |
50 |
25 |
25 |
Show
|
| cmocka (job), by using it (private) |
in general: embedded platforms
in detail: embedded C or Linux based |
linux and google |
I try to take them serious. if I can't read it like a book or simply do not understand something, I complain. |
Under 10 seconds |
3 |
3 |
1 |
Show
|
| directly in client - server scenarios |
- |
- |
- |
5-30 minutes |
50% |
30% |
20% |
Show
|
| I typically add unit and integration tests when I am working on something that could have runtime errors that could result from my code, like parsers, algorithms, etc. In Rust I often avoid writing tests by using the type system to make certain error cases impossible. |
I typically develop on Ubuntu, but I recently got a Mac with Apple Silicon, and I also use Windows. Basically, everything. |
I typically use VS Code + Rust Analyzer + Cargo. |
We often develop in a mob, allowing for live code review. |
11-30 seconds |
80 |
15 |
5 |
Show
|
| Using some flavor of test driven development. |
No specific system in mind, usually application-specific. |
Primarily VS Code and everything that comes with it. |
Currently depends on the project, but generally pretty high-level. |
1-5 minutes |
60 |
20 |
20 |
Show
|
| gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
my collegues can answer this better than i could. |
31-60 seconds |
20 |
20 |
20 |
Show
|
| gtest unit tests |
Cortex M4 dual controller system with BLE |
my collegues can answer this better than i could. |
my collegues can answer this better than i could. |
31-60 seconds |
20 |
20 |
20 |
Show
|
| For newly created software units, unit tests are applied during development ( first the logic is implemented, then tested).
For legacy code, tests are done by looking at the integration level. |
Low power Microcontroller 32-bits. |
Eclipse, IAR , Visual studio, azdo, EA. It depends on the project. |
Done via Pull request |
1-5 minutes |
20 |
50 |
30 |
Show
|
| unit-tests, integration-tests |
medical embedded devices |
VS-Code, Docker, gcc (cross compiler), gdb debugger, git, microsoft azure for change management and continuous integration |
one reviewer, using pull-request workflow |
11-30 seconds |
50 |
30 |
20 |
Show
|
| Currently, either Cucumber or just running the code against CI when I push to Git. |
Small evaluation board from ST fitted with a custom display |
Visual Studio Code
STM32CubeIDE |
We do mob programming, so we don't *usually* do code reviews as everyone is generally in the loop.
Sometimes when we have to do solo work, though, we'll pull 1-2 people in to ensure the code is sane. |
31-60 seconds |
15 |
15 |
70 |
Show
|
| ideally most of my day -- above 80% -- spent in the happy place of the red-green-refactor micro loop. 3 months into job here, about 5% in that place, 95% in what Geepaw calls GAK activity, others, yak shaving. |
bare metal rust some kind of STM processor (new to this space I am) |
rust; c++ for the legacy bits; applying strangler pattern to eliminate that, in hopes of 100% rust 0% C++ |
we mob - reiews are real time; asynchronous review (I'm looking at you, Git PR) are for those sad souls who default to solo. |
Under 10 seconds |
10 |
45 |
45 |
Show
|
| unit tests, integration tests, regression tests |
ARM Cortex M |
VSCode/Vim, GDB, STLink, Rust/C++ |
done by Mob/Pair Programming |
1-5 minutes |
3 |
4 |
3 |
Show
|
| Using google-test. Write code, then test.
Target is 100% coverage, for application logic down to device drivers. |
Embedded ARM device |
CLion
VS-Code
docker
clang, iar,
git
gitlab
|
we do a code-review per pull-request. review is done by second person, a pull-request holds code from 3-5 days of work. |
31-60 seconds |
40 |
30 |
30 |
Show
|
| As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
Done through pair coding and at the pull requests |
1-2 hours |
50 |
30 |
20 |
Show
|
| Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing. |
Arduino, embedded linux, embedded Windows, desktop exercises. |
Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio |
varies by project, from zero to by weekly to pairing |
31-60 seconds |
10 |
40 |
50 |
Show
|
| |
|
VS code |
|
4-8 hours |
8 |
5 |
7 |
Show
|
| Writing unit tests for existing code |
Uses java script and python |
VS Code |
They go through peer review processes |
5-30 minutes |
33 |
33 |
33 |
Show
|
| Test in development environment, code review, test on target platform, then whole system integration testing. |
Laptop running Windows 10 |
Visual Studio, git, VMWare |
Peers review code individually and provide feedback prior to an online meeting where we review the code, what its supposed to do, and what it actually does |
Under 10 seconds |
60 |
20 |
20 |
Show
|
| We are using Google Test / Google Moack for Unit testing and we have own frameworks for end to end testing.
TDD is encouraged but not implemented correctly in the company. |
STM32 |
The team can provide information |
We use the four eyes principles and all code is checked before being committed. We have recently moved to using Git Pull requests for all activities (last week ) |
5-30 minutes |
40 |
30 |
20 |
Show
|
| - Manually on the target according test reports |
New development of a laser system for eye surgery - responsible for the FW in distributed system (Win10 (GUI); Linux (System controller); 7 x FW w/o OS). Subsystems with FW connected as slaves over USB to the System controller |
- STM32CubeIDE
- Enterprise Architect (UML/SysML) |
Only if searching a bug or if listed as a step in test report. No formal procedure defined. |
11-30 seconds |
70 |
10 |
20 |
Show
|
| As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not.
(In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) |
n/a |
GitHub, Docker, Azure |
Done through pair coding and at the pull requests |
1-2 hours |
50 |
30 |
20 |
Show
|
| PyTest, UnitTest, other test API, and trial and error |
I am currently developing test software using a Windows 10 Lenovo x64 machine, but plan to create tests to be deployed and triggered on Raspberry Pi 4's for actual CDCI. |
Visual Studio Code IDE, Thonny IDE (for Pi Pico or lightweight Pi 4 work), GitHub Actions |
I do not have code reviews as a Verification Technician. |
1-5 minutes |
40 |
40 |
20 |
Show
|
| yes |
embedded platforms |
Tornado 2.2 |
peer |
31-60 seconds |
33 |
33 |
33 |
Show
|
| By unit tests using Google Test |
Insulin Pump System with two MCU's (stm32l476xx & stm32wbxx) |
- Visual Studio Code
- SEGGER J-Link
- Azure DevOps
|
The code reviews are done by a reviewer using the pull request feature of Azure DevOps. |
1-5 minutes |
30 |
50 |
20 |
Show
|
| On unit-test level we are using CppUTest. |
We are using a 3 cpu system |
Eclipse
VisualStudioCode |
Code reviews are done in Pull Requests of Azure Dev Ops by a technical leader. As a basis there are review report templates bound to our internal processes. |
11-30 seconds |
30 |
20 |
50 |
Show
|
| We are at the moment in the setup phase of our project.
We plan to use Google Test for Unit tests. And we want to have automated integration tests by using Robot Framework.
In my past projects testing was mainly done directly after implementation, but for my feeling mainly rudimental tests. There was a seperate System Test deparment. |
Embedded platform for ethernet fieldbuses. The plan is to use C++ where possible. |
Static Code Analysis
Azure DevOps
|
Currently in setup phase of the project and no fixed process is implemented so far. |
31-60 seconds |
40 |
20 |
40 |
Show
|
| Unit tests are executed during the build. Higher-level tests are still largely manual and/or ad-hoc. I'm seeking to improve this at the organizational level. |
Military vehicles, ranging from microcontrollers to desktop-level machines. |
Eclipse. |
We need better participation. Authors need to do a better job making it easier for others to participate.
We also fundamentally need to reduce the need for them by adopting better, more modern practices that include a lot more testing. |
11-30 seconds |
60 |
20 |
20 |
Show
|
| Depends on the project. In the project I am now: program the device, hope it works. The testing team will do the unit tests later. |
Medical device containing two microcontroller (one main, one supervisor) and bluetooth connectivity. It injects drug. |
VS Code / Eclipse, Parasoft, C, Azure Dev Ops, conan package manager |
Done in Pull Request in Azure Dev Ops. Sometimes thorough, sometimes not. |
5-30 minutes |
4 |
3 |
3 |
Show
|
| pytest or unittest |
embedded instruments, proprietary serial bus interface, gui is touchscreen, outputs are relay contacts, 4-20mA analog signals |
Rust software, C++ embedded, python system integration test automation |
team reviews |
5-30 minutes |
4 |
1 |
2 |
Show
|
| I test it manually and we have a test team |
Congatec QSeven imx6 running Linux |
VS 2019 for C# |
Code review is done mostly if there is a big change. |
5-30 minutes |
50 |
25 |
25 |
Show
|
| I test the code manually before I pass it on to the test engineers. |
A YOCTO linux systems that communicates with nodes that contain STM32 microcontrollers. |
Visual Studio
Qt Creator
STM32CUBE IDE
Texas Instruments CCS
Matlab |
We work with GitLab. When we want to commit larger changes, we normally create a merge request and ask a colleague to review the changes in GitLab. |
11-30 seconds |
40 |
30 |
30 |
Show
|
| Unit Tests, UI and integration tests are done manually |
Windows, Linux, Mobile Devives |
Visual Studio |
I dont have time for code reviews nowadays, they were done when I started programming |
Under 10 seconds |
70 |
10 |
20 |
Show
|
| fully from user standpoint |
Blackfin BF537 DSP |
VisualDSP++, Visual Studio 2019 |
rarely review |
1-5 minutes |
2 |
2 |
5 |
Show
|
| Currently NUnit and Ceedling (CUnit).
Write failing test, write code behind the test, make the test pass, commit, refactor a bit where necessary. (I could use more discipline on the refactoring bit). |
It's kind of a typical pre-web embedded system comprised of a microcontroller for data acquisition (embedded C) communicating to a single board computer running a Windows C# application via a CAN bus. |
For the embedded bit, use Atmel studio (now MPLAB X), but found that CLion is a more navigable IDE (refactoring tools inclusive).
For the C# side it's Visual Studio with the Resharper plugin (for unit testing and refactoring/autocomplete tools). |
We don't currently do any code reviews. At best in Valley Forge, it is one developer per product/product line. Would like to start - emphasis on readability/testability over style. |
31-60 seconds |
15 |
30 |
55 |
Show
|
| Manually functional with unit or simulation |
Windows PC and embedded windows PC |
Visual studio |
By my self |
31-60 seconds |
60 |
15 |
25 |
Show
|
| unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
using ccpcheck to find defects |
1-5 minutes |
40 |
40 |
20 |
Show
|
| unittests, software in the loop for Signalprocessing |
Devices: Digiphone, ESG, Ferrolux
Software written in C on a Blackfin from Analog Devices
|
Visual DSP, Cppcheck, Jenkins, Matlab |
using ccpcheck to find defects |
1-5 minutes |
40 |
40 |
20 |
Show
|
| Manually check the functionality. |
Self-developed PCB board, controlled by an FPGA. |
Intel Quartus II, Visual Studio |
I'll give the code to a colleague to test.
|
31-60 seconds |
20 |
40 |
40 |
Show
|
| A combination of automated unit tests and manual testing on hardware. Historically, this has skewed mainly towards the latter, but in the last couple of years I have begun to test as much as possible via unit tests.
As a project team, we are looking to perform more automated testing on hardware. This is not something I have been involved with personally yet, but am looking forward to learning about it. |
We typically develop hand held products used for electrical test. These products often involve multiple processors, and need to be designed with safety in mind. |
Hstorically, IAR tools, but we're moving to GCC and other open source tools that play better integration with CI tools.
We develop primarily on Windows, although there is some Linux/WSL work (particularly with CI).
We also use Matlab/Simulink. |
We try to review all code that is integrated with the develop branch. There is no formal process for how. Sometimes it is done via screen share, sometimes via Bitbucket pull request. Reviewees nominate a reviewer familiar with the subject. |
Under 10 seconds |
70 |
20 |
10 |
Show
|