- This topic has 11 replies, 3 voices, and was last updated 6 years ago by
.
-
Posts
-
Looking at the documentation, it appears that unit testing is only supported on the target hardware. Is there any way to have unit tests run on a windows machine? Since unit tests rarely exercise the actual hardware but typically just test the written application code, is there a way to run the tests without the debugger? I would like to have my unit tests run on the build server which is a Windows machine that does not have my embedded board attached.
Hi,
This is not supported yet, so the easiest workaround would be to use a Linux VM (or the Windows 10 Linux Subsystem) and run the tests there.
Hi,
If your code relies on any STM32-specific code (like HAL), it won’t automatically run on Windows either and will need to be ported using some sort of an abstraction layer (you can manually add Linux configurations to an Embedded project via VS Configuration Manager and then copy the .vgdbsettings file from another Linux project). The amount of porting effort will be the same for both Linux or Windows (the only advantage of running tests on Windows would be no need for a Linux VM, but this is solved with the Windows 10 Linux Subsystem).
Hello, anything new here? I’m also interested in running Unit Tests on windows machine without need for real hardware / debugger – to be able to run it on Windows build server. Our target is STM32 as well. We are just starting with Unit Tests, playing with TinyEmbeddedTest, but we may probably go for any framework.
Hi,
Are you looking into running hardware-specific tests in a simulator (fully supporting the emulation of the STM32 hardware), or are trying to run high-level tests that do not have any hardware dependencies?
Hi, thanks for your reply.
For beginning, high-level tests without hardware dependency will be fine. But to get higher test coverage, I think hardware-specific test will be nice to have as well. I’m just starting with Unit Tests stuff, so I’m not sure what will be easier to achieve.
Our project is running about 2 years without any Unit Tests, so we would like to add as many tests as reasonable to the existing code, as well as try to cover majority of new code with tests. Any amount of tests should be better than current – zero 🙂
Hi,
Given the low cost of the modern MCU evaluation boards, we would advise simply running the unit tests on the hardware. To make the board available to the build server, we could supply a small tool for “sharing” the boards – you should be able to run it on a machine with one or more boards attached, and then configure the build server to run the tests on those boards remotely.
In order to run the tests without any hardware at all, you would need to refactor your code, introducing an abstraction layer so that most of the common logic can run in a Windows (or Linux) process as well as on the device. Another option would be to modify QEmu to emulate the STM32 peripherals (we use it internally for VisualGDB integration tests), however it would be relatively complex and exposing the evaluation boards to the build server should be much easier.
Hi,
Our build server is running on Azure cloud, so we can not attach evaluation board directly to it. Tool for sharing the boards could do the job, so we are definitely interested in that tool. Please let me know how shall we proceed to obtain it.
Thanks for nice explanation of testing possibilities without hardware, we will consider it. Hopefully evaluation board solution will do the job.
PS: Bit off topic, but which testing framework would you recommend for embedded devices, e.g. 512kB flash, 128kB RAM CortexM4 MPU (STM32L471)? I was able to start some tests on TinyEmbeddedTest only so far, but it may be just my lack of knowledge. I have some issues with TinyEmbeddedTest as well, but if I won’t be able to resolve it, I will start a new forum thread to not mix topics.
Hi,
No problem. We should be able to include the device sharing tool in the next major VisualGDB release (please allow 3-6 months until we will have a preview build with this).
If you would like to get it earlier, we could offer it as a paid custom feature (typically 5 takes business days), but if your timing allows, we would advise simply waiting until we deliver it as a part of our regular release schedule.
Regarding the test frameworks, TinyEmbeddedTest is actually designed by us as a minimalistic test framework with minimum possible overhead on embedded devices, so we will more than appreciate your feedback on the issues you encountered and will be happy to make it better. We would appreciate it if you do start a separate thread about that, as it would make it easier for other users to find that discussion.
It’s not so critical for us, so we will wait for official release of device sharing tool.
TinyEmbeddTest works nice so far. If anything occurs, I’ll start new thread to help you with improvements of it. Thanks for your help so far.
- You must be logged in to reply to this topic.