| Using google framework, we write test cases for the code under test. |
Earlier network elements now, data collectors for water meters. |
c cross compiler for nxp platform |
Reviewers follow the review guidelines document and review the code. |
1-5 minutes |
10 |
4 |
3 |
Show
|
| Generally top-level integration testing when changes are made |
Embedded Linux + FPGA w/soft microcontroller |
vim, CMake, Intel Quartus |
Very basic reviews on each pull-request |
5-30 minutes |
10 |
5 |
85 |
Show
|
| Run on hardware in the debugger. Hack my code to hardcode values or execution paths. |
STM32 Cube |
STM32 Cube IDE (eclipse), CLion |
All code must be merged via pull requests. All pull requests must be approved by invited reviewers |
1-5 minutes |
60 |
5 |
35 |
Show
|
| Manually. No unit tests or any automated tested machinery. |
Linux on x86. Basically a mini-desktop platform with a few GB of memory. |
CMake, GCC, Clang format, VS Code, Visual Studio |
All changes to the main dev branch must be submitted as a PR on bitbucket, req. one reviewer. |
11-30 seconds |
5 |
0 |
5 |
Show
|
| we don't |
embedded device |
stm32cubeide |
NA |
1-5 minutes |
50 |
0 |
50 |
Show
|
| Functional testing |
STM32 Cortex-M7 |
STM32CubeIDE |
Pull requests are reviewed by the team before merging into the main branch. |
31-60 seconds |
7 |
4 |
3 |
Show
|
| Manual testing. Very limited automated testing |
Embedded devices |
N/A |
Peer reviews for all pull requests |
1-5 minutes |
40 |
20 |
40 |
Show
|
| With log files and debugging statements |
Linux-OS based machine |
Visual Studio Code and GDB |
Pull requests are created that reviewers can comment on |
5-30 minutes |
20 |
40 |
40 |
Show
|
| run it |
- |
- |
- |
31-60 seconds |
50 |
10 |
40 |
Show
|
| Hardware Debugger, Print Statements, Tracealyzer, GPIO Toggling. |
STM32 Microcontroller with Cortex-M7 core, Free RTOS, GUI UI, pulse real time measurements |
STM32 CubeIDE, Clion |
I like to pull the code down and go over it in the IDE. |
5-30 minutes |
60 |
10 |
30 |
Show
|
| unit tests with google test |
pc windows software, android apps |
Qt Creator, android studio |
too few developers |
31-60 seconds |
70 |
15 |
15 |
Show
|
| debug and functional tests |
embedded devices |
Platformio for Arduino |
no code review |
11-30 seconds |
33 |
33 |
33 |
Show
|
| Currently I am writing testcases using utest, and ensure that all test cases are passed. |
Right now I'm working on a cellular module for water meters. |
IAR Embedded workbench, Visual studio, GIT |
Before merging the code into remote branch, my code will be reviewed by all other team members |
1-5 minutes |
5 |
3 |
2 |
Show
|
| I normally test the code on the target using a programmer/debugger tool. |
The target is an embedded system based on 16bit or Arm microcontroller |
I usually use the IDE supported by the microcontroller manufacturer. |
It's usually done by myself in order to find mistakes or improve code, sometimes I ask to colleagues |
1-5 minutes |
30 |
20 |
50 |
Show
|
| As a developer write and test against unit tests. Commits are tested by an automated build system. |
Thermal printers controlled by an embedded Arm system. |
Qnx Momentics, PCLint, CppuTest |
N/a |
5-30 minutes |
60 |
10 |
30 |
Show
|
| Code first, run existing tests, and create a new test if necessary. |
Target system is either an x86 VM, or an ARM chip. |
Eclipse |
Done with either a review software, or pair programming. |
11-30 seconds |
30 |
30 |
40 |
Show
|
| Python UnitTest framework unsing the web interface of our device (kind of system test) |
ARM Cortex A based embedded device running on Linux |
Eclipse, GCC/GDB, PyCharm, GitLab, Teamcity |
|
31-60 seconds |
10 |
40 |
50 |
Show
|
| Python unit tests and teamcity CD/CI |
Embedded linux and rtos |
Pycharm, Visual Studio Code, Virtual Box |
I often make silly mistakes |
31-60 seconds |
5 |
2 |
3 |
Show
|
| Unit testing, acceptance testing, manual testing for the GUI |
PC |
Visual Studio |
We are a team of two: we review each other |
11-30 seconds |
60 |
20 |
20 |
Show
|
| We currently have a few MSTests. Everytime we commit something these tests are executed.
Also before committing we execute the tests manually. |
Windows PC |
GitLab
Visual Studio
Confluence
ReSharper |
We have a small team (2 people). So usually before committing we look at the code together. |
11-30 seconds |
50 |
20 |
30 |
Show
|
| Mostly manual testing |
Embedded devices (cortex A with Linux or M architectures with RTOS) |
Eclipse, Embedded Wizard IDE, |
I've never had, except for small parts of code when they were needed by one of my colleagues |
31-60 seconds |
50 |
40 |
10 |
Show
|
| Mostly with automated scripts for unit, integration and regression test. Some unit tests (not driving the development), some debugging.
|
Portable audio analyzer, dual ARMv7 running Debian 10 on Linux kernel 4.9.11 with RT patch |
Eclipse CDT, Visual Studio, VS Code, PyCharm, Git/GitExtensions, TeamCity |
Only occasional. Some pair programming. |
31-60 seconds |
50 |
25 |
25 |
Show
|
| Some unit tests written after the code is "ready", plus integration/system tests. A a lot of manual testing... |
Hand-held device: MCU running RTOS, display, keys input, storage, USB, cloud connectivity |
-- |
Don't have code reviews at the moment, but planning to start doing it |
31-60 seconds |
30% |
15% |
55% |
Show
|
| sometime asserts or googletest |
Ultra low power embedded systems (bare metal without OS) on 16 or 32 bits (ARM) MCUS |
Mostly eclipse based tools, sometimes VSCODE |
Not yet really doing those unless a colleagues asks to do them |
1-5 minutes |
33% |
33% |
33% |
Show
|
| write and run automated unit and integration tests |
we develop for an ARMv7 CPU in printers |
Momentics, svn, git, vim |
we have a remote, asynchronous code review process, allowing experts in any time zone to give input |
1-5 minutes |
30 |
30 |
40 |
Show
|
| debugging mode,
non regression test on target side |
embedded system |
vendor IDE |
no code review |
1-5 minutes |
40 |
30 |
30 |
Show
|
| Unit tests |
Currently our target system is SPC58NH92C5 (CHorus10M) - triple core, PowerArchitecture CPU
|
CMake
Greenhills compiler
other inhouse tools
|
Walkthrough the changes |
1-2 hours |
2 |
2 |
6 |
Show
|
| By debugging and stepping through code to ensure proper execution |
A test instrument that contains a handful of separate boards controlled by one central processor |
IAR EW
Visual Studio
|
Loose peer review |
31-60 seconds |
4 |
3 |
3 |
Show
|
| Manual hands-on testing of product. |
Embedded system running Android OS |
IAR Workbench |
Lead SW developer checks over code before it is committed. |
31-60 seconds |
6 |
3 |
1 |
Show
|
| - |
Mostly STM32 |
An IDE, development board and a logic analyzer. |
- |
5-30 minutes |
40 |
10 |
50 |
Show
|
| Manually |
Its a motor tester (Test and measurement equipment) |
IAR Embedded workbench. |
Colleagues. |
31-60 seconds |
10 |
5 |
5 |
Show
|
| Mostly functional/manual level testing. |
Various embedded processors, incl Renesas, Arm & PiC |
VS Code, VS Studio, MPLab, IAR compilers/debuggers |
Not normally done in past at VF, if done then informal/ad-hoc when needed. |
11-30 seconds |
20 |
40 |
40 |
Show
|
| With great difficulty. Unit testing not included in the code base, mostly; impractical to retrofit. I often change some small piece of complex calculations, validating results is hard. For more re-usable, general, new components, I unit test. |
Windows (desktop, some embedded stuff), and other embedded platforms (with no OS). |
mostly Visual Studio, some IaR embedded workbench, some Android Studio. |
I asked once for a code review here, got nothing. No one has ever asked me to do code review here. |
31-60 seconds |
6 |
2 |
2 |
Show
|
| We have application and test engineer run validation tests on the product. |
Our products from bare metal C, windows embedded using C++ to Windows running hybrid C++/C#, Android |
IAR compiler, Visual studio, Android studio, Borland C++ |
Lead software developer would review my subversion check-ins and send back code review comments. |
11-30 seconds |
5 |
2 |
3 |
Show
|
| It is tested manually by others by following test plans. Prior to others testing it, I perform manual tests of my own to verify functionality. |
We have multiple target systems but my current system is Android on top of Linux. |
Android Studio |
I perform code reviews on each check in and provide guidance for improvements. |
Under 10 seconds |
70 |
15 |
15 |
Show
|
| I had a SW dev course that used Maven as a testing platform for all our Java and JS code for a web app project. Test functions were written for each new code piece prior to development. |
Not sure. |
Not sure what the team is currently using. |
Not currently on the team. |
5-30 minutes |
70 |
0 |
30 |
Show
|
| Manually by hand or by giving the code to others in the company. |
Unsure as well. |
Android studio |
Minimum and stylistic. We have pretty large and infrequent commits. |
Under 10 seconds |
30% |
20% |
50% |
Show
|
| I test code manually by running the program and performing different behaviors. |
unsure |
Android Studio, Visual Studio, SVN |
They are informal comments made after code is submitted |
11-30 seconds |
50 |
25 |
25 |
Show
|
| Test cases are written in Ceedling for an Embedded C project, and NUnit for a C# project. Note that sometimes the test cases are written "after the fact".
Additional tests done by QA after a release candidate is ready. |
It is a two Embedded processor system, one runs code written in C, the other in C# running on WinCE. |
Debugger, simulator, demo code, test harnesses, lab tools. |
If code reviews are done (if at all) they are informal. |
Under 10 seconds |
50 |
25 |
25 |
Show
|
| Unit Testing, CI pipeline |
SSD contollers. |
GNU GCC tool chain, JTAG debuggers, SIMICS enviourment. |
we use the code review system that comes with gerit. |
1-5 minutes |
10 |
40 |
50 |
Show
|
| Writing Unit tests. On actual H/W sometimes |
storage Controller |
Visual studio code, Source Insight |
None started in current company |
1-5 minutes |
40 |
40 |
20 |
Show
|
| PC Simulator |
Arm based controller |
gcc, gdb, VS Code, Source Insight |
- |
31-60 seconds |
40 |
30 |
30 |
Show
|
| I have test application which call the functions in a required flow. The Test APP has the added functionality to test all the interfaces for user. |
Multiple OS Like Windows,Linux,ESXi. The system should satisfy the pre-requisites SW and HW
|
Microsoft Visual studio
Linux GCC Compiler
Cross Platform Toolchain
|
The Code is reviewed by Self and Team with tools |
30-60 minutes |
20 |
60 |
20 |
Show
|
| We have testing environment and CI pipeline. |
lenovo laptop with 16GB RAM and window10 OS |
vim or visual studio code |
we use gerrit for code review |
1-5 minutes |
20% |
20% |
60% |
Show
|
| Code development yet to start |
SOC firmware |
NA |
NA |
31-60 seconds |
70 |
10 |
20 |
Show
|
| I am new to Marvell.Previously we have used Unit tests written in C and ran over visual studio |
It is a SoC with 12 ARM R8 and 2 ARM M7 |
Visual studio code |
I am new to Marvell and I dont know the answer to this. |
1-5 minutes |
40 |
20 |
40 |
Show
|
| We do manual and Automation testing.
In Manual testing, we test for particular fix/functions by running specific test.
In automation testing, we test complete code by running different test cases, which covers maximum code. |
OEM Servers with Marvell Products |
Microsft Visual Studio
Linux
Perforce
Git |
Code review is done among different team members, where code changes and unit test result shared. |
1-5 minutes |
40 |
30 |
30 |
Show
|
| PC simulation environment using python |
ARM based controllers (SoC) |
VS Code, Source Insight, GCC Toolchains, WSL |
Peers review using gerrit |
1-5 minutes |
40% |
30% |
30% |
Show
|
| Either on Simulator or EVB. |
I use a Windows Host. |
ARM Compiler 6, VSCODE |
I review the code changes thoroughly. |
5-30 minutes |
50 |
30 |
20 |
Show
|
| I have not tested the code yet |
I dont know about the Target System. |
SourceInsight, VScode, Vim etc |
I am a new Joinee and I have not created any code reviews yet |
2-4 hours |
30% |
30% |
40% |
Show
|
| PC Simulator written in Python |
SOC |
Arm compiler/debugger |
Internal |
5-30 minutes |
50 |
30 |
20 |
Show
|
| UT in visual studio |
Windows, Linux |
VS Code, Git, Jira |
peer reviews, SME reviews |
1-5 minutes |
60 |
30 |
10 |
Show
|
| On Simulation, Emulation, Evaluation board and form factor board. |
SOCs |
Arm compiler, SOC boards, custom simulators and boards, HW debuggers, protocol analyzers |
It is a good practice to get it reviewed by experienced person |
31-60 seconds |
30 |
30 |
40 |
Show
|
| Design unit tests around the feature that I am working on and try to test it.
|
1. Various HBA solution FW interfaces and OS interfaces
2. HW blocks |
gcc, vim, ctags, cscope, gdb, git |
1. Check functionality
2. Security checks e.g., memory leak, dead lock
3. Tests performed |
1-5 minutes |
3 |
3 |
4 |
Show
|
| Unit test using NUnit testing framework. |
I want to write a code in efficient way and delivers within a short period of time. |
- Visual studio community
- stm32CubeIDE |
I use a checklists |
30-60 minutes |
4 |
2 |
4 |
Show
|
| Legacy products are tested with a handful of unit test and some system tests. No test harness is used. With new products I use Ceedling and cmock. |
Some legacy 16-bit Freescale and newer 32-bit Cortex-M based products |
STM32CubeIDE, LCPXpresso, MCUXpresso, CodeWarrior |
Git pull requests |
31-60 seconds |
33 |
33 |
33 |
Show
|
| - some unittests written after the fact
- some feature tests (python / behave, on a pi that talks to the test setup) |
microcontroller (mostly stm32, esp32) with freertos |
- iar for arm and stm8 projects
- vscode for esp32 projects |
- gitlab merge requests
- one or two team members review code
- usually takes a few days |
31-60 seconds |
45 |
20 |
35 |
Show
|
| Unittest (Cpputest in target Simulator), Feature test (BDD/Gherkin/Python behave), Manual exploratory testing |
Typically custom electronics based around various types of STM32. |
IAR, VSCode |
Development is done in branches, other team member review code through gitlab before merging. |
11-30 seconds |
20 |
70 |
10 |
Show
|
| no testing of code |
industry software |
MS Visual Studio |
none |
5-30 minutes |
40 |
20 |
40 |
Show
|
| Unit tests, system tests, babblesim |
nRF series |
VsCode |
We do the majority of our reviews on Github with a minimum requirement of two approving reviews. |
1-5 minutes |
60 |
20 |
20 |
Show
|
| We have separate developers that make tests in the Jenkins framework |
We use NCS, which is based on Zephyr RTOS |
VS Code, SEGGER Ozone |
We use Github, need 2 approvals from code owners to merge a PR |
31-60 seconds |
45% |
10% |
45% |
Show
|
| I do TDD by default. But I have also some part of our legacy code base still covered by black box characterization tests (Approvals) |
Any embedded, but also some backend processing intensive related software |
Visual Studio Professional and Eclipse |
We don't do code reviews. When there are complex things to develop or refactor, we usually pair |
Under 10 seconds |
45 |
50 |
5 |
Show
|
| CI using GitHub actions, Python Unittest, Actual Hardware, Zephyr shell |
Production Test Environment for development kits, shields etc. |
VSCode
West
GCC
|
We're a small team mostly doing reviews of eachother's code. |
1-5 minutes |
35 |
25 |
40 |
Show
|
| manual |
STM32 variants running bare metal or freertos |
IAR workbench, gitlab, github, gcc, make |
minimal if people have time. |
11-30 seconds |
50 |
20 |
30 |
Show
|
| Unit testing |
Zephyr |
VS Code |
- |
31-60 seconds |
50 |
20 |
30 |
Show
|
| unit testing, on-target tests, integration tests. |
embedded wireless system. |
gcc |
reviews are productive, much less wasted time on nits than previous jobs. |
1-5 minutes |
50 |
25 |
25 |
Show
|
| One of our codebases uses CppUnit for our higher level software modules. Legacy repositories we rely purely on functional testing driven from our serial interface, IoT communication, Mobile Apps, etc. |
Few different MCUs used in our products. They are all Cortex-M (M0, M3, M4). ~1MB flash/100s KB RAM. |
GNU toolchain, J-Link, VS code, RS-232, |
Use GitHub for source control and require a PR for merging all code. |
1-5 minutes |
60 |
25 |
15 |
Show
|
| On-target |
A cortex-m4 based board running FreeRTOS |
J-Link
GDB
Saleae
|
Done online, 2 approvals required |
11-30 seconds |
50 |
20 |
30 |
Show
|
| Unit testing with a test harness and then system level testing using a custom Python test harness that interacts with the hardware system. |
varies based on the project |
A wide range. Visual Studio Code, Eclipse, CppUTest, Metrix++, Understand, etc |
usually done with customers |
Under 10 seconds |
70 |
20 |
10 |
Show
|
| CppUTest |
Glass panel displays for experimental planes & other light aircraft. |
Docker, VSCode (including VSCode debugger), GDB |
We use Crucible and GitHub pull requests |
5-30 minutes |
3 |
3 |
4 |
Show
|
| Test apps, unit tests |
Windows |
Visual studio 2019, 2022 |
- critical parts reviewed in pairs |
31-60 seconds |
90 |
5 |
5 |
Show
|
| Stepping through code during a debug session
Debug.Assert
reading through the code and double-checking
unit tests (both written in advance and after the code) |
MS Windows |
Visual Studio |
none |
11-30 seconds |
50 |
30 |
20 |
Show
|
| Something with unit tests, but most just by running it in the test lab. Note that the communication requires testing many simultaneous connections, testing connection failures etc. and this may not be feasible with the unit tests. |
Not sure what the question means. |
Visual Studio 2022 |
We don't do code reviews too often. Usually only when fixing an already reported critical issue. |
5-30 minutes |
40 |
10 |
50 |
Show
|
| running the application in various use cases, checking the code and its behavior/results in debug mode |
Microsoft Windows, Docker containers based on Linux (Ubuntu, Alpine) |
Visual Studio 2022 |
not using code reviews, just rarely |
1-5 minutes |
50 |
30 |
20 |
Show
|
| In the last couple of years I started using unit tests. So in general I write the code and in parallel I create unit tests on the code I'm writing. When I don't have unit tests, I test it in debug mode. |
I usually work on Windows and I develop .NET projects. |
I use Visual Studio 2022 and MSTest to generate the unit tests. |
I don't have a specific check list. I check complexity, readability, error handling, functionality. |
31-60 seconds |
50 |
25 |
25 |
Show
|
| old ms unit tests, custom testing tools |
web, desktop, mobile |
vs 2022, vs code |
we do code reviews for critical pieces/when doing changes in someone else's code |
2-4 hours |
5% |
10% |
10% |
Show
|
| To be honest i don't for the most part - when I do I write unit tests in xunit but I never used a formal TDD approach |
We target .NET systems |
Visual Studio |
We don't really do code reviews, except after I've deeply changed code written by somebody else |
11-30 seconds |
50 |
10 |
40 |
Show
|
| Manual testing, screen capture testing |
Web, Mobile, Windows |
Microsoft Visual Studio
Microsoft TFS |
Only if requested |
2-4 hours |
60 |
10 |
30 |
Show
|
| Black Box/White Box/Use Case/Boundary Condition/Code Review driven scenarios/Regression |
Small scale embedded systems |
Device specific development environments, MP Lab, Code Composer, Atmel Studio, Segger, VS Code |
Small group, 1-3 people, criticality driven level of rigor. |
1-5 minutes |
40 |
30 |
30 |
Show
|
| Functional validation, black box, white box, error path validation |
Embedded systems, now mostly ARM targets, multiple processors |
MPLAB, Segger, GCC, Eclipse |
Nonstructured |
30-60 minutes |
40 |
20 |
40 |
Show
|
| I do TDD by default. But I have also some part of our legacy code base still covered by black box characterization tests (Approvals) |
Any embedded, but also some backend processing intensive related software |
Visual Studio Professional and Eclipse |
We don't do code reviews. When there are complex things to develop or refactor, we usually pair |
Under 10 seconds |
45 |
50 |
5 |
Show
|
| I do TDD by default. But I have also some part of our legacy code base still covered by black box characterization tests (Approvals) |
Any embedded, but also some backend processing intensive related software |
Visual Studio Professional and Eclipse |
We don't do code reviews. When there are complex things to develop or refactor, we usually pair |
Under 10 seconds |
45 |
50 |
5 |
Show
|
| Limited unit testing, mostly scripts that regression test the code running live on the end product. |
Variety, but the current product is using a Cypress PSOC 6. |
GNU, clang, visual studio code, python for scripting, etc. |
Every PR require's at least 2 sign offs and we have several static analyzers running. |
31-60 seconds |
50 |
25 |
25 |
Show
|
| Unit test |
Microcontroller |
Keil |
No review |
1-5 minutes |
7 |
2 |
1 |
Show
|
| cpputest, docker, pmccabe, cppcheck, GitLab CI |
We program for ARM 32 bits chips, mainly NXP |
Visual Studio Code
NXP S32 Design Studio
Segger tools
Busmaster |
None at the moment |
11-30 seconds |
20 |
30 |
50 |
Show
|
| Burn and churn :-) That's why we are taking the course. We have went through many of the TDD solutions/warnings given - Fix Code breaks other code, invalid one-off inputs are not seen until the code is in the field........ |
Migrated from PIC32 to STM32F |
Mfr's IDE, have started to dabble with MS Visual Studio Code, but in the past I edited with Sublime |
2 embedded coders, sometimes working the same project, and we use github code review's to merge. |
31-60 seconds |
45 |
10 |
45 |
Show
|
| Yes |
MSP430 and Silabs MCU |
IAR Embedded Workbench |
coding standards, Completion of logic and for better logic and any performance issues |
1-5 minutes |
1 hr |
2 hr |
2 hr |
Show
|
| run against data locally |
Nvidia Jetson |
VS Code, Git |
Few to none, small team |
11-30 seconds |
33 |
33 |
33 |
Show
|
| Requirements tests in Gerkhin, Integration tests in Rust Test with wrappers for target external interfaces, Unit tests in Rust Test on workstation. Test driven all the way down. |
Mix of ARM M7 with RTOS and ARM A-series with RT-Linux or RTOS. (Large-ish memory embedded systems.) |
Git, VS Code, rust-analyzer, clippy, cargo, probe-rs, lldb |
Primarily continuous with mob programming. There is a formal process for addressing certain risks. |
31-60 seconds |
40 |
45 |
15 |
Show
|
| Using TDD for writing code. A mix of unit, integration and verification tests will be written around requirements. |
Embedded Rust on a safety critical system. |
Rust in VSCode |
Unstructured as the team primarily mobs. Code created outside the mob will be reviewed ad hoc. |
Under 10 seconds |
100 |
100 |
0 |
Show
|
| We use TDD with the built-in Rust tests. We set up cargo-watch to run the tests on save |
Initially, it's two NVidia Jetson boards and a PC (not sure if it will be Windows or Linux) |
VSCode
Vim |
Don't do 'em because we're always mobbing. |
Under 10 seconds |
38 |
60 |
2 |
Show
|
| Unit tests, HIL tests, integration tests |
Multi-processor safety critical |
Rust tool-chain
|
Mob/Collaborative review. Real-time full-team |
1-5 minutes |
40 |
40 |
10 |
Show
|
| Manually |
Linux embedded system |
SVN, GitHub, VS Code |
I need to learn some of the things. |
5-30 minutes |
5 |
1 |
4 |
Show
|
| Code is tested using our unit tests within our source code and our integration test which are written as cucumber tests. |
Target system is an Nvidia Jetson Nano. |
Github, vscode |
We do not have standard code reviews. |
11-30 seconds |
30 |
50 |
20 |
Show
|
| TDD, unit tests + integration tesets |
tbd |
VS Code, github |
tbd |
Under 10 seconds |
40 |
20 |
40 |
Show
|
| Unit tests, integration tests (including hardware in the loop) |
Target system is a multi-processor system with several ARM boards. |
VSCode, WSL, Rust Analyzer |
Continuous reviews as part of mob programming practice |
11-30 seconds |
15 |
35 |
50 |
Show
|
| Test in layers starting with unit tests. Then go up to from component test, integration tests, system, and release tests. |
Embedded system communicating with PC. |
VS code and rust. |
What reviews? |
1-5 minutes |
50 |
40 |
10 |
Show
|
| Applying test driven development, we first write a failing unit test to drive writing production code features until the unit test passes. We refactor or repeat the process and write HIL integration and verification tests using Gherkin and Cucumber. |
The current target is a 2 GB NVIDIA Jetson Nano. |
VSCode, Github |
Following mob programming software development, our team has real time code review. |
Under 10 seconds |
35 |
60 |
5 |
Show
|
| Mainly using end-to-end and functional tests |
Battery management system |
Clion, vim, gdb, openocd, git, compiler explorer |
Pull requests are made per feature change. One approver actively working on the project is required |
11-30 seconds |
60 |
20 |
20 |
Show
|
| I am EPM in Marvell, so not programming anymore |
I am EPM in Marvell, so not programming anymore |
I am EPM in Marvell, so not programming anymore |
I am EPM in Marvell, so not programming anymore |
5-30 minutes |
0 |
0 |
0 |
Show
|