Training Preparation -- Current Practices of 100 Attendees

How do you test your code? What is your target system? What development tools do you use? What is your code review practice? How much time does it take to do an incremental build, load, and start running your code so you can start to test it? What percentage of your development time is spent coding? What percentage of your development time is spent testing? What percentage of your development time is spent debugging?
Building, uploading and running it, and then create a situation where changes in the code will show. Sometimes I need to provoke the system or even introduce another bug to see how the system reacts. Then, if the change seems to work, test the change in multiple different situations/over a period of time Robot firmware mainly Git, Jira, Microchip studio, VS Code We review git merges, or when someone is unsure about something 1-5 minutes 60 20 20 Show
On bench setup or in real application. Autostore cube storage, automated logistics solution STM Cube IDE 11-30 seconds 50 10 40 Show
Tested manually. Bare metal embedded plattform. Clang, Git, GitLab Multiple reviewers are approving the code changes before merging into the master branch. 1-5 minutes 40 20 40 Show
With the goal of uncovering issues and bugs as early as possible. Basically i'm doing manual unit testing. Manually manipulating input to modules/functions by any means in order to test all edge cases that I can think of. In addition to this I would also do targeted/specialized integration testing before merging any code. Robot firmware running on STM32-controllers. Requiring high degree of robustness and stability while also keeping focus on functional details. Aspects related to performance and durability of the robots are important as well. Git. Jira/Confluence. SonarQube. A bunch of internal tools. Partly good. 5-30 minutes 10% 70% 20% Show
cargo test STM32Fx ( and some NXP ) gcc , VS code, git, rust All merges should be independantly reviewd and pass CI Under 10 seconds 7 2 1 Show
Some unit testing, a lot of manual testing STM32 microcontroller VS studio Code Merge request before a branch is merged to master. Reviewers will look through the code and accept/decline. Build server makes sure the branch builds, but does not run any tests. 11-30 seconds 20 50 30 Show
Simulation via Simulink - Requirements tests, integration tests, baseline/equivalence tests. And on target hardware / system. Embedded control system. Compiler Debugger Code Editor Version Control (Git) Simulator (Simulink) Often slow. But thorough. Under 10 seconds Don't know Don't know Don't know Show
Testing directly on the target hardware. No unit tests as such. Embedded system based on STM32 MCUs for controlling robots for storage system. Eclipse Visual Studio Code GCC Code review are done upon merge requests by another software developer (lead) 1-5 minutes 60 20 20 Show
System tests, automatic jig tests and local happy testing. B1 robot is a multi CPU system with real-time requirements and a fair bit of dynamics (motor control). gcc, VS Code, pytest (for integration testing), Confluence for doc, Jira, git, Gitlab. Clang-format checks on commits (new). SonarQube for analysis We have MR (Gitlab merge request) that needs to be approved before they are allowed into the master branch. We have some preliminary checklists of what to check and are currently requiring 1 approver and preferably also a second reviewer. 5-30 minutes 2 2 6 Show
GTest Not sure, I'm a new engineer at this company. VSCode, mingw, gdb/make/ninja, arm toolchain. Not sure, I'm a new engineer at this company. 1-5 minutes 40% 40% 20% Show
Gtest, GMock Bare metal Arm Cortex-Mx MCU's VS Code, Eclipse Before any merge request there is always min. 2 colleagues which go through the code for style and compatibility. 11-30 seconds 50 10 40 Show
By running it on the target. With debugger, print statements or normal operation depending on how much has changed. Embedded systems, STM32 Git, Gitlab, Jira, Eclipse, Visual Studio Code One or more relevant persons will look through the changes and confirm it does what it is supposed to and adheres to the defined coding guidelines. The author is responsible for testing the code and making any requested changes. 11-30 seconds unknown unknown unknown Show
Bench testing (have a std set of instructions and debuggers) + we have dedicated team to do unit testing Linux Different IDEs We use code collaborator to do code reviews. Usually 2-3 reviewers+ moderator are present 31-60 seconds 4/10 4/10 6/10 Show
Depends on the feature/issue I'm working on. For feature, I use T32/lauterbach to add breakpoints and verify the states of the variables. For issues I re-run the failing tests and recommend adding additional tests to increase coverage. ARM R8 based embedded system. Bare metal programming. lauterbach, ARM toolchain n/a 1-5 minutes 4 3 3 Show
Running on actual HW that has attached debugger Pre-commit tools Simulator Enterprise SSD Visual Studio GCC / GDB ARM cross compiler / assembler T32 debugging Peer review with review system 5-30 minutes 20 30 50 Show
Run test cases SSD Lauterbach T32 emulator Our code need be reviewed by at least one member from each of 3 groups. 31-60 seconds 4 3 3 Show
Modify code to force code paths. DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. IDEs, VI DO NOT PROVIDE ANY CONFIDENTIAL, SENSITIVE OR EMBARRASSING INFORMATION IN YOUR REPLIES. 5-30 minutes 30 40 30 Show
bench test, some regression test cycles ARM based SOC lauterbach t32 UART Firmware traces code collaborator, standard review process with 2 peer and 1 moderator 1-5 minutes 2 2 6 Show
Targeted testing / injection on real devices and in simulation environments, plus automated sanity test suites Proprietary SSD devices ARMCLANG, SlickEdit, Git, Visual Studio, make Some automated coding standard checking, but loosely enforced. Emphasis on correctness and functionality over style. Quality and scope varies depending on factors unrelated to the code (schedule, reviewers, etc.) 1-5 minutes 80 10 10 Show
Regression testing various: SystemC model Python models/parsers NVMe SSD device FW VS Code, GDB varies: For model development, optional Bitbucket centric reviews. For FW, code collaborator required. 11-30 seconds 40 20 40 Show
bench tests, debugger manipulation, integration tests Many CPUs, lots of hardware acceleration. VSCode, Trace32, home made. use of review bots is handy. can take a long time to get a review completed. 1-5 minutes 40 40 20 Show
Bench test and putting breakpoint in the code I used Linux and windows both as target systems Source Insight for C++ development I make sure to file a bug if I see an incorrect implementation 1-5 minutes 30 40 30 Show
using host applications developed by third parties or internal test teams Linux, windows based systems connected to SSDs ARM DS5, VS studio, Source Insight I look at code structure first then logic 4-8 hours 30 30 40 Show
different team does the testing. no unit testing Samsung ASIC ARM, Bash, batch reviews consist of syntax and logic verification. 1-5 minutes 60 10 30 Show
Test applications using the APIs of my code. Mostly embedded devices based on a ARM solution, with Linux or ThreadX. The toolchain for our targets based on the supplier delivery (SCons, bitbake, gnu compiler chain for the build system. Lint and CppCheck for static code analysis. We mostly use GitLab. On older projects based on ClearCase, we use a ms-word review-template. 5-30 minutes 40 40 20 Show
build, and afterwards by flashing the module, Wireless module, with a lwm2m client, connects to a web server and helps with provisioning of an embedded SIM. source insight, vim/gvim. +Qualcomm tools to debug. normally done in gitlab 5-30 minutes 2 3 5 Show
As unit test with bash scripts, with intention for automatisation in CI (jenkins). If not possible only manually. Especially for audio topics to recognize if audio path really enabled we have few sensor options to realize woking software. Embedded system with mostly ARM processor, main software delivered by processor producer, do we advancing the system and make it compatible in the customer environment. Source Insight, Notepad++, propiritary tool of the the processer producer (Qualcomm, Mediatek), git (last years), before clear case as version management Reviews in git lab: Check for syntax problems or obviously better to handle functions. To get deeper in the right 5-30 minutes 6 2 2 Show
As I am mostly bugfix others code or just enhance vendor code, tests are usually very specific. Often this is done by individual agreements (case-per-case) with system test department. several SoC's form Qualcomm, MTK, ... plain text editor + vendor specific env. project specific. Currently: most changes are to be reviewd by at least one another developer using gitlab. 1-5 minutes 30 10 60 Show
Jenkins CI server 64 bit ARM/Cortex processor for 5G products GIT,Jenkins The code review is automatically initiated by pushing the code changes to the server. Sometimes it is challenging to understand the functionality when the review contains a lot of code. 5-30 minutes 7 2 1 Show
Ci, Jenkins Several Base band Processor systems gcc, make, cmake Gitlab tools 5-30 minutes 60 20 20 Show
Jenkins, CTS Android Compiler, Source Insght, Lauterbach debugger Organized with Jira tooling 5-30 minutes 20 60 20 Show
manually Mobile Phone SOCs several GitLab based merge requests documented in Jira 30-60 minutes 33 33 33 Show
unit tests, on target tests various vendors using different OS, e.g. Siemens, TTPCom, Qualcom, MediaTek, Intel gcc,g++,vendor compilers, ... make, cmake, scons, ... gdb, Lauterbach, language debuggers vim, emacs, SourceInsight, Eclipese, ... gprof, gcov ClearCase, git, mercurial Jenkins, Gitlab, Jira, Confluence, ClearQuest ... using Gitlab merge requests 1-5 minutes 50% 30% 20% Show
I write every line of code imaginable, as fast as I can, and use a binary search to find the bugs sdf asdf asdf 11-30 seconds 45 45 10 Show
unit or bench test by developer and then test cases by test group Linux Debian or VxWorks workbench performed with each release 30-60 minutes 0 0 0 Show
internal group cellular tracker devices with various sensors for perishable and healthcare market na internal Under 10 seconds 0 0 0 Show
Testing by running on target - testing function and unhappy paths. Linux on arm, VxWorks on X86 Eclipse, Workbench/Tornado We do them, from an internal check list enumerating items to check. 1-5 minutes 35 50 15 Show
I build my own testing classes/blocks/methods/functions to unit test my code vs expected results. Windows, PLCs/Controllers For my current job I use ISaGRAF, VS Code, Visual Studio and StarTeam for version management. Code reviews with peer developers. 1-5 minutes 25 45 30 Show
Most of my project history is embedded oem projects where I am the hardware and firmware engineer. The firmware tests are functional when bringing up a board. When writing the application firmware the testing is done with some rough data simulations and then validated on the machine itself in our lab. As features are added the firmware is sent to customers so they can begin using their equipment and provide feedback. Typically embedded boards with 32bit microcontrollers. I also work quite a bit on embedded ARM Linux platforms. Visual Studio MPLAB Atmel Studio QT Creator Before a project starts or a new complicated phase I will have architecture reviews with another engineer to get second opinions on my intended approach. On collaborative project reviews would happen before a release. 11-30 seconds 50 25 25 Show
Lots of hands on testing. Make a change, test it. Arm Cortex M0+ and M4 MPLABX, SEGGER, NXP, Logic Analyzer, Oscope, DMM Code reviews are test driven and informal. 11-30 seconds 30 40 30 Show
Debuggers - test code Embedded Linux Linux VM, Eclipse, cross compilers, GDB Look for patterns to fix. memory leaks, potential errors, some static analysis 1-5 minutes 30 50 20 Show
Debugging on a device. Our required IDE for PLC development does not allow code to run unless loaded on a device, so we have to load it on a device and debug in order test the code. In the past I have attempted to translate the ST code to C# to help develop some functionality, but testing the C# code not mean the ST code does not have any issues. I write code for a PLC (iPro). Custom version of ISaGRAF as the IDE and StarTeam for VSC. For my hobby, I also use VS Coe and Visual Studio with their tools like nuget, git, etc... Not frequent and we don't often have the time or knowledge on a project (3-4 devs working on 3-4 projects) to do thorough reviews. It is often only reviewing code that has issues. 1-5 minutes 30 70 70 Show
Debug sessions and manual testing Most of my target systems are small microcontroller-based systems. Some are connected (BLE, Wi-Fi, USB) and some are stand-alone instruments. Simplicity Studio Notepad++ Visual Studio MPLab X Android Studio XCode I have not had any code reviews, as I have historically been the only software developer on the projects I have worked on. 11-30 seconds 20 50 30 Show
Make a development build and bench test it. I primarily work on our SS/E3 platforms they are a building control system for HVAC, Refrigeration, and lighting Eclipse I schedule a meeting with my team and walk through the changes I made to the code. During the walk through I explain my thought process on why I made the changes I did. 5-30 minutes 50 10 40 Show
manually Embedded Device Visual Studio Code Ad hoc 11-30 seconds 70 20 10 Show
In association with the hardware. Microcontrollers. QT. STM Cube, Peer reviews. 1-5 minutes 60 25 15 Show
Most test are done by testing with hardware and hardness. Few tests are done by some software unit test. it is a system, with a control software, a gateway and control boards. The cloud will be included in the near future. MS Visual Studio, and Eclipse Editor. Sometimes I do, sometimes not. But I prefer to do it. To check the logic needs some more thoughts or not, and coding is efficient or not. 5-30 minutes 1 7 1 Show
not very well linux visual studio 2017, 2019, 202+, Eclipse IDE, intelliJ have had a few, but not very many. 11-30 seconds 60 30 10 Show
Running it against real data Wi-Fi IoT device, embedded 802.15.4 devices, mobile devices, and cloud systems As a manager... excel, windows, etc. N/A 5-30 minutes 0 0 0 Show
Custom unit test and functional testing are my primary test methods. I also occasionally use UART prints to log things for longer tests. ARM processors code composer by TI, CubeID by ST, Eclipse 2 to 3 engineers participate in reviews. For changes we use beyond compare to identify modified code sections and those are reviewed in a meeting with peers. Under 10 seconds 60 30 10 Show
Unit test with Debugger Automated tests using serial port to inject data. Mostly STM32 mcu IAR Workbench J-Link debugger We have mostly offline peer review to verify that the developper did not do any obvious mistake and the the code is consistent with the design. 1-5 minutes 6 2 2 Show
single step, use print statements, use an app to check functionality various microprocessors Keil, Visual Studio, Eclipse use online code reviews where everyone can comment on the code 1-5 minutes 3 5 2 Show
Ad-Hoc test using debugger. Write simple test code or scripts along with developed code, but not systematically done. Embedded IOT device with cellular, WIFI, Bluetooth connectivity Eclipse-based compiler, debugger. Infrequent use of Google-Test. Use JIRA to review most if not all changes and features. 5-30 minutes 90 10 10 Show
Some level of unit testing, white box testing (single stepping) and functional testing Mostly work on developing autopilot systems for small drones. Largely use STM ARM Micro-controllers running u-COS. Also embedded Linux Visual Studio, Eclipse, Keil uVision. Use Crucible and Git for code reviewing depending on the code base. Crucible is most widely used but we are trying to migrate from SVN to Git 31-60 seconds 50% 20% 30% Show
Test after development Lock system Python, Testrail n/a 5-30 minutes 0 100 0 Show
Write unit test. Single board computer using a STM micro. IAR tool chain. VScodium editor. Usually with one other person. 31-60 seconds 90 3 7 Show
For our C code, alot of times we have done manual unit testing, or pseudo-automated, more as the real device. Embedded Fw running on ultra low power micros, such as ST micros. Visual Studio C++ for Sw Apps, IAR Ide for Embedded Fw We review C code for functionality, coding style, correctness on a regular basis. 1-5 minutes 40 40 20 Show
With console printouts, debuggers, and analyzers I am coding for a circuit controlled by an stm32 microcontroller IAR embedded workbench, saleae logic analyzers I am new to dormakaba, and have not yet had a code review. Under 10 seconds 40 20 40 Show
Manual techniques: print statements, log files, observing behaviors, using a debugger if the IDE allows Embedded firmware in door locks and controllers. Operating systems are a combination of Linux, FreeRTOS and bare metal Eclipse, Visual Studio, vi Currently: Informal meetings, 2-3 participants Future: GIT pull requests 1-5 minutes 50 30 20 Show
develop/execute unit tests manually. Separate team does functional and integration testing. Mostly manual but have developed automated testing for some projects. Most of our products are embedded systems that deal in access control. Locally, our product line focuses on safe locking systems. IAR IDE, Visual Studio, others peer reviewed 1-5 minutes 40 30 30 Show
Since we ( my team ) are not developers we don't deal with unit testing. We design and implement regression testing using frameworks such as Selenium, FitNesse Windows. Android Visual Studio Mostly I am concerned with use cases and how best we are covering them as oppose to coding standards. I leave that to my senior SW team members 1-5 minutes 20 30 50 Show
Developers use Brute force, Product Assurance (PA) does black box testing. IAR - STM32, MSP430 IAR, VSCodium, Meld, AStyle, Git (migrating from SVN). Visual Studio 2019, Corporate provides Git, Jenkins, Sonar Qube Up to this point had Subversion as VCS, are now in process of migrating to Git. Once we are on Git will be using pull-requests for code reviews. Up to now it was by using a patch or by examining changes once committed. 31-60 seconds 6 2 2 Show
Unit test with CppUTest. Gecko Micros Docker, various IDEs, virtualization (VmWare, VirtualBox) We conduct code reviews in Bitbucket. 1-5 minutes 20 15 30 Show
Initially when setting up communications - extensively use logic analyzer. Usually standalone test apps for other tests - to check data input crcs, frequency etc. Usually ARM based microcontroller (Mostly ST - F4, F7) projects. Uvision Keil, Visual studio, Eclipse Usually we would do SVN Diff for modifications and do an informal review. We have started migrating to Crucible for formal reviews. It can pull the changes from SVN and track code review comments which are marked as unresolved until resolution. Under 10 seconds 40 30 30 Show
Run on simulator to check basic functionality since it's easier to control the environment. Then load and test on hardware to exercise the code. Embedded Linux on Xilinx Zynq, running on small air vehicle. Visual Studio, Keil IDEs. Git/Gitlab for source control and code reviews. Performed in gitlab by peers of varying experience levels. 1-5 minutes 50 30 20 Show
I have a small legacy project in C#, that I was able to recreate the core using TDD and NUnit, also tried to apply SOLID, TDD guided by ZOMBIES and other advises from you, Uncle Bob and Martin Fowler. My main project, who pays the bills, is in Harbour, which does not have a Test Harness nor Code coverage. I'm currently writeing a free, opensource test harness for it inspired by CppUTest, JUnit, NUnit and xUnit. Mostly Linux and Windows desktop. For embedded I experimented with ESP8266. JEdit, VsCode / Visual studio community, docker, subversion, git, virtualbox I do a lot of pair, even before hearing about agile. So I avoid later code reviews as much as I can. And I always have a tight relationship to the user to avoid misunderstandings. 5-30 minutes 25 25 50 Show
Unity for unit testing and a hardware in the loop test with inhouse python scripts. A terminal using a stm32 mcu sending data from satellites. arm-gcc, cmake, unity, cppcheck. If the pull request is small, we found something to say. If the pull request is huge, sometimes, we juste accept it because it's too complexe to understand. 5-30 minutes 70 20 10 Show
Unit Testing, low-level functionalities on embedded hardware (manual runs) and high-level functionalities on x86 HAL (partial emulation) in CI Integration testing with test procedures remotely commanding embedded software and verifying result of execution. Partial integration testing with software running on x86 emulation. Spacecraft subsystems, either FRAM-based MSP430 (12Mhz, ~40KB firmware size, ~12KB data memory), or Cortex-M3 (100Mhz, ~64KB firmware size, 64KB RAM). Visual Studio with VisualGDB extension GCC toolchains (x86, MSP430, ARM) and VC++ (x86) Through pull requests for major features, not always for smaller. Lot of room for improvements. 11-30 seconds 50 20 30 Show
On device testing/verification We develop on a variety of microcontrollers like the MSP 430 and 8051 chip IAR We user PRs where our team members will review and approve PRs 5-30 minutes 20 50 30 Show
separate binaries and test scripts Linux on ARM SBCs, PIC Microcontrollers, and getting into ARM STMicro chips soon as well. Visual Studio, VS Code, QTCreator We typically do these ad-hoc, with usually 1 reviewer. 31-60 seconds 40 20 40 Show
Unit tests, higher level functional tests, benchtop simulators that mimic the ocean in some small way, systems tests in our test tank, test at sea. Various ARM processors, currently developing a STM32H7A3 based system. Not a lot of heavy duty computing but we do need to run control loops at a deterministic rate (usually less than 100 Hz). And we have to interface to a lot of instruments. Visual Studio I grew up as an engineer at a defense contractor where design reviews of all kinds were a critical part of my job. I've been at MBARI, an academic oceanographic research institute, for 25 years and formal design reviews are not so effective. 11-30 seconds 20 50 30 Show
Unit testing, functional testing. - - Done through Bitbucket, all team members are always included, requires a minimum of 2 approvals. Under 10 seconds 40 50 10 Show
Unit testing with Unity/FFF. Tests are generally written after the code. Tests are built into our CI pipeline to be run on commits. We also have Hardware In the Loop testing for integration level testing STM32L5 M33 based hardware; bare metal finite state machine based application; GCC/CMake toolchain; The product is a micro linked to a custom ASIC radio chip over SPI GCC, CMake, CLion, Azure DevOps We generally work in feature/bugfix branches, and then do PRs in master branch. The PRs need to be reviewed by the 2 other firmware engineers in the team. The obvious weakness to me is the lack of focus on "how good are these tests" in the review. Under 10 seconds 4 2.5 3.5 Show
I work mostly in mobs. Most of my coding in my current job is during katas. We use TDD with cyber-dojo. I would like to take TDD katas to the embedded world. The embedded developers in my area do MIL/SIL testing. There also are validation teams upstream who do a combination of manual and automated testing. The area I work in develops Autosar based C code for embedded vehicle ECUs. 70% is model based, 30% is hand coded. Matlab, Embedded Coder, Simulink,BTC Tester, Target Link Peer code reviews are a mandatory step for all code. They also review models and data dictionaries. 1-2 hours 50 25 25 Show
Unit tests, run the code use the device (user perspective) CubeSat VisualStudio, Visual GDB While reviewing git pull requests (MS DevOps) 11-30 seconds 50 30 20 Show
For re-usable/library code I use Ceedling to do some unit testing, but it has been difficult to find a way to use this on our production code. Most SW testing is manual bench testing with a debugger, and integration/system testing in the product. I've used Robot Framework with python to do some automated integration tests on our products, but I would say that the majority of testing is done using a debugger or python scripts. The products I work on are embedded controls for electric motor protection devices or variable frequency drives. We run on bare metal with a cooperative scheduler. Vendor-provided Eclipse-based IDEs and build tools with various debuggers depending on the target. I use python for writing test scripts/tools. I use vim for more involved coding (I use Windows Subsystem for Linux to get vim and other Linux tools). I use Microsoft DevOps to do code reviews via pull requests with git. Typically I look at diffs if I am familiar with the codebase, or I will look at the whole files more if I am not familiar with the code. 31-60 seconds 20 30 50 Show
We are doing two "types" of tests. Unit tests and Continuous integration tests. Unit tests are done by the Software Engineers when we add some code. Continuous integration tests are done by our Test Engineer. Our application runs on a STM32L5 MCU. We also ported it to x86_64 to facilitate the unit tests. Visual Studio Code on Ubuntu STM32CubeIDE STM32CubeProgrammer Azure DevOps Usually we do a PR with several code reviews. We put comments where we want discuss something and when we agree on everything, we accept the PR. 31-60 seconds 55 15 30 Show
After having written a code following a phase of planning, I write unit tests for the code and try to cover the possible outcomes of software units as extensively as possible. Nano-satellite subsystems powered by constrained hardware with space flight heritage (TI MSP430, some STM32 architectures). Used to working against code size limitations, to favoring deterministic behavior, and efficient CPU/memory usage tradeoffs. Git, IAR Embedded Workbench, Visual Studio, Visual GDB, GCC, Logic analyzers, Oscilloscopes, Matlab They are usually only done when examining pull requests to the main development branch following the development of a feature. 11-30 seconds 20% 20% 60% Show
behave off target testing + on target (+ unity) various m0 / m2 boards IAR workbench, VM, scons, atlassian tools, git pull request in git reviewed by 2+ other developers 5-30 minutes 30 40 depends Show
Generally compagny I worked don't use unit test. When I'm free I try to use TDD and gtest but I think knowledge are missing to do it right. I work mainly on the gui, so I cannot goes in details about the system. vim, linux command line, tmux... Qt creator to be able to debug it. ON this compagny code review is new, so not so much. On my previous job, I was lead developer, so I introduced code review. OUr quality increase a lot. The time to develop a feature grows by 40/60% but the bug report decrease to 80%. 5-30 minutes 3 1 6 Show
Using Unit Tests to verify that my code still works after changes have been made cooking device with a modern user interface to provide an easy and automated experience for preparing meals in the commercial sector QT Framework Usually done in gitlab over merge requests 11-30 seconds 60 10 30 Show
write unit tests / QtCreator i've used Pair Programming, Over-the-Shoulder and Merge-Request to help reviewing codes 1-5 minutes 5 2 3 Show
Predefined Test cases. Embedded Linux Visual Studio Code - 5-30 minutes 40 20 40 Show
As Qt is platform independent, tests by the developer are ususally done in a simultation environment on a Linux Server. That is fast an convenient. Only after successfully testing the code, the code is cross-compiled and flashed onto the embedded target device. Embedded Linux, ARM CPU, Everything provided by Qt (Qt Creator, Qt Designer, QML Profiler etc) Valgrid, Lint, Jenkins, Git, Gitlab pipeline Very new. Not entrenched in mindset. Is seen by some as a hassle. But that is the wrong attitude. Code reviews can not make sure code is error free, but helps with architecture, style and grave mistakes. 11-30 seconds 70 10 20 Show
Unittests and AcceptanceTests Qt/QML UI, C++ backend, Python system tests VSCode, PyCharm, QtCreator Currently at least 1 reviewer and the gitlab pipeline. Sometimes also pair reviews. 11-30 seconds 50 30 20 Show
I am working most on legacy code, try to write some kind of unit tests to prevent regressions. Embedded System, working with C++ / QT / QML QtCreator / gcc / clang (code analysis), git, We started doing merge requests with coding reviews 11-30 seconds 40 20 30 Show
Write test cases with Qt Test framework. Yocto based Linux on ARM Qt-Creator Clang-Tidy and Clazy Review over Gitlab MR 1-5 minutes 30 30 40 Show
QTest, screenshot comparison Embedded linux QtCreator, Visual Studio git lab merge request. I prefer gerrit 1-5 minutes 30 20 50 Show
Most of testing is done by manual testing. Few unit and integration tests (via QtTest) are written. But it doesn't cover full code. Target system is under UNIX system. We have two main applications (frontend/backend) running and communicating between each other. QtCreator CMake We use merge request via Gitlab to validate or not modifications. At least two MMI members are put as reviewer. 1-5 minutes 30 40 35 Show
Manual testing, unit tests with qTest embeded linux with touch screen QTCreator - 11-30 seconds 60% 20% 20% Show
If applicable I try to write tests preemptively after creating a class skeleton/interface for example. As a seconds step fill it with the actual functionality and see if it fulfills the requirements. Embedded Linux Qt Creator, VS Code, Visual Studio Gitlab merge requests. If required, face-to-face / via video call) 1-5 minutes 50 25 25 Show
mostly manual with defined test procedures and unittest Commercial kitchen cooking appliances C++ Builder, DBSchema, QtCreator rare 5-30 minutes 50 30 20 Show
using small unit tests, debugging code with print-outs Our target consists of three parts of : basis, cooking system&application and mmi running on a linux machine VS Code gitlab every bigger change is review by a merge request 11-30 seconds 30 20 50 Show
testing on the machine using test cases; using logging outputs its a linux machine qt creator sometimes I'll do a review with a colleague 11-30 seconds 60 10 30 Show
Highly dependent on the project and on the customer's wishes and needs. -- VS Code Qt Creator IntelliJ Highly dependent on the project and on the customer's wishes and needs. 1-5 minutes 33 33 33 Show
i am testing my components either on a Intel-PC, or in a kind of simulation on the target. arm-single-core controller, linux, 2 main processes running (mmi and base), too less RAM, too less computing power,... tools provided by the OS, QT-creator, geany, gdb,... we are designing components of the cooking oven. The collaboration in our system is the part, causing problems because in many cases the behaviour of these components cannot be foreseen. The big issue is not the SW, but the system behaviour... 1-5 minutes 20 40 40 Show
- manually - some qtest module tests - embedded device qtcreator are in planning to do 1-5 minutes 33 33 33 Show
Mostly by hand, because big chunks of the code are not testable apart from other big parts. weak hardware ARM device QtCreator, MySQL Workbench, Python- and Bash-Scripts Code Revies must not be done, but for middle to big changes i use them with other experts of this code modules. Usually I tell the colleagues how it should work and they comment. If needed, we do multiple rounds. 11-30 seconds 50% 25% 25% Show
I am using google test. To bring the system in the right state and set the needed preconditions is most challenging for me. Furthermore, the test converage could (as always) be improved but lacks of setting up the test. embedded linux with ARM processor QtCreator My colleague and me are doing regularly code reviews on the component we are developing. It helps us a lot and it would be great if we have more of it in the whole project. First attemps are made by introducing merge requests. 11-30 seconds 40 20 40 Show
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 actually started doing those in the past year. I submit a MR in gitlab and get valuable feedback from my domain-colleagues 11-30 seconds 50 20 30 Show
The tag cloud words are from attendees 'Current test practice'

Make this into a word cloud

Select text below (triple click), copy, then try one of these tag cloud generators
jasondavies word cloud generator - colorful
tagcrowd - lets you show counts