I can't figure out how a desktop environment developer test his code. Usually, a C or C++ programmer compiles his code an then run it (i'm not one of those programmers, i'm a web one).
So, you usually build your gui application over some kind of desktop environment (windows, mac os x, gnome, kde, xfce...), sow how they build and test their gui desktop?
And if this is a silly question, how does a kernel programmer test his code? for example linux kernel? how do you know that what you just wrote works?
Testing is a very broad term there are many types (partial list):
unit tests - test small pieces of code. test that the code behaves as expected.
system tests - test whole application in real world scenarios.
performance tests - test what is the performance of the application or part of it.
GUI testing - test operation of GUI elements (not so common as automated tests)
static analysis - compiler warnings on steroids
dynamic analysis - at a minimum memory checks - check mem allocations and usage
coverage tests - check that all code is executed.
formal verification tests (very advanced) - e.g. check when assertions/assumptions are broken.
Kernel code can be debugged by connecting using a 2nd computer (host). Virtual machines uses the same principal and simplify the setup but can't always work as HW might not exist in the guest VM.
The kernel (all OSes) has trace mechanism(s) for printing progress/problems. In Linux the simple trace is shown via the dmesg command (prints a cyclic buffer).
User mode code can easily be stopped and debugged via a debugger.
Desktop Environments
Testing Desktop Environments in real world scenarios can be kind of annoying, so the developer would have to watch out for every small error he makes, if he doesn't, he will have a hard time developing the DE.
As stated by #egur, there are multiple ways of testing his code, the easiest one and most important (but cannot be used in some cases, of course), he can test that code in a simplified program.
A Desktop Environment consists of many parts, however, in your case, I suppose you're talking about the session manager (or window manager) which is responsible for almost everything. So, if he were to test that, he would simply exit his current DE and use the new executable. In case of some error, he can always keep a backup of the old executable or fix the faulty code using some commandline text editor (like vim, or nano).
Kernel
It's quite hard to test, some kernel developers just write some code and make sure it's fine and compiles, then simply let his users test (by ACK'ing the code, etc.), then it can be submitted into the kernel code. Reasoning behind that is, the developer may not have the hardware needed to test the code.
Right now, you can compile and run the kernel in usermode (UML) if you have heard of it, so some developers may go for it. However, some developers may also want to test it themselves (They of course back up the current kernel incase of a screw up).
The way to test a desktop application is related to the way of control the application unassisted or remotely.
The Cross Platform GUI Test Automation tool (I don't know if this project has a web) project helps you to chose the interfaces/libraries required to solve the problem.
In Linux[1] uses the accessibility libraries to control the application, you have Cobra[2] for Windows and PyATOM[3] for MacOS, but I don't know what kind of technology uses in this platforms.
http://ldtp.freedesktop.org/wiki/
https://github.com/ldtp/cobra
https://github.com/pyatom/pyatom
Related
In our company we develop bare metal embedded software for microcontrollers. Until now we have been using manual unit test on targets or simulators, specially for Renesas microcontrollers (RL78 and RX families). We're planning now to go into automatic unit tests. The idea is to integrate them in our existing CI system.
At this point we've got a dilema. Until now we've been running unit test using the same compiler and target (or simulator) that later has been used to deploy the software into production. We'd like to maintain this approach, as the developers (and everybody) specially appreciate to test and deploy using the same conditions. So the idea would be to take a testing tool/library programmed in C that allows as to compile and run the tests in an embedded environment using a simulator. (Ex. http://www.throwtheswitch.org/unity)
But, on the other side, we cope with two upcoming situations that make the dilema arise:
We're more and more going to Cortex uC, where it's more difficult to get specific simulators to allow automation. (Ex. Renesas RA family)
Many of the advanced testing tools are developed in C++ and thought for PC environment using gcc/g++ compiler in a x86 architecture, that doesn't match that of the Cortex targets compiled using arm-none-eabi-gcc that we foresee to use.
So, at this point, we're wondering, and this would be my question, what kind of reliability can have unit tests run using gcc if our final target will be a Cortex uC and the binaries will finally be generated using arm-none-eabi-gcc. indirectly I'd be asking for the differences between gcc and arm-none-eabi-gcc when compiling for different targets.
I'd appreciate feedback from someone knowing about gcc internals that could have coped with the same kind of problem.
Thanks in advance,
Ignasi Villagrasa
Generally, simulators are useless, but especially so for production testing. Since it is an embedded system, you want to test software and hardware both - testing software without the intended MCU and hardware in place is just nonsense.
If you insist on using fluffware like simulators or PC "test suites" then realize:
It is an incomplete test which does not test core functionality of your product.
It cannot be used to test drivers/hardware-related code, it can only test abstract algorithms.
It can only be used for development testing, never for production testing.
As for how to correctly test your specific embedded system, it depends on the application and what the product is supposed to do. If you do your projects by the book then you have: Specification, leading to implementation, leading to tests. The sole purpose of a test is to verify that the implementation follows the specification.
So if the specification says that the product should activate 10 relays, you will need to flash the software onto the live MCU on the real PCB and a correctly performed test then verifies that all 10 relays get activated as they should.
This complete and correct product test cannot be done in any other way. So ask yourself if you actually need the incorrect and incomplete simulated test at all. Perhaps your development-related testing should focus on more meaningful things like design reviews, coding standards, static analysis, code reviews etc.
I am trying to get started developing unittests for my embedded system, actually its a firmware that was already developed a while ago, now we want to add CI to it and start this by writing unittests.
I read blogs like
https://dmitryfrank.com/articles/unit_testing_embedded_c_applications
or https://interrupt.memfault.com/blog/unit-testing-basics and they recommend to implement the unittests via a unittest framework as unity, cpputest and so on and so on. I tried to figure out how to make this run on my windows machine that I use at work but it seems tedious and prone to problems etc.
I also tried to start working with the microsoft vs unit testing framework but got discouraged after running into problems here, too. I think this can't be so hard, it shouldn't take so much effort to start writing the first littlest test...
Do you have experience with this and what would you recommend? Is it viable to do this on Windows? Should I push my boss to let me use a VM, WSL or a Machine that runs Ubuntu? In the end I would like to transfer the CI System to a lab pc (edit: this pc would then also be connected to the hardware, flash it, maybe run a debug build on it and compile some answers that it gets from the hardware... but now I want to talk about the unit test), so if I start developing on Ubuntu now, I will have to deal with this lateron, too...
Maybe a lot of thoughts but I feel a bit overwhelmed with the problem and don't know how to start.
Thanks for you replies, people!
Edit: The discussion I am looking for is not about whether unit testing for embedded systems is useful or the right approach (also interesting but I would like to seperate it) . It's about the question whether it can be fully developed under Windows or whether a Linux System is necessary to be efficient.
I'm taking my university's trial by fire C course and I need some help with the environment I'm programming in.
So, all assignments have to be uploaded to a linux remote server. All the tests suites they provide are run on this sever, using that servers specific compiler settings. (Which is why I'm really worried about just using an IDE, finishing the project, and then uploading the files to the server. I'm scared the compiler settings will be different and everything will just stop working when moved into a different environment).
Since coding on a remote at the same time as 1000 other students results in lag and crashes that makes the already unintuitive and painful experience of using VIM in a puTTy window even worse is an unbearable experience, what are my options?
Has anyone got some advice on what would be the best option for me in this situation?
1) I learned writing bootloaders and tested it using bochs. Now, I want to add GUI to by bootloader. I have googled but didnt hit on relevant sources for that. I even tried searching github for existing projects. I checked out this question. But is there any way to install some graphics libraries or include x-window-system APIs in my code to give in a GUI env (e.g: Chameleon, GAG) instead of including just a splash image ?
2) Is there any possibility to add python execution environment during bootloader stage, so that when I step in protected mode, i could add some python scripts?
3) How to add standard C/C++ library support?
Thanks in advance.
It might help if you told what kind of bootloader you're talking about. I work with this daily and most of what you're saying seems like crazy talk. LOL.
Usually bootloaders are very small startup program that takes a decision on what to load next. Some bootloaders contains features for "flashing" the main application. (The main app often cannot flash it self.) The bootloader being the first piece of code the processor meets, makes it very critical. You do not want it to fail nor upgrade it. Hence bootloaders tend to strive for smaller is better.
As for your questions.
3) I've never seen a bootloader not written in c. So it got that one covered. (They exist though) C++ you would have to compile the whole project with c++. (Not a problem.)
1) and 2) I'm not sure what "protected mode" is, but to include eg python or x-windows you would have to include the source into your project. Here's the thing. Usually bootloaders are baremetal code and code like X isn't. You'd have to include a whole lot of other code as well. And you'd end up with a bootloader at 500 mb. Usually you strive for something like 5 kb.
The splash image is usually done through low level interaction with the graphic card.
If anyone else is interested in bootloader development, I can recommend to look at uboot. It's a linux (mostly) loader and is rather easy to find your way through. And it already supports a lot.
Is there a way I can create a virtual instance of gcc compiler on the client browser when the client opens my website??
By doing so, I can directly pass the user .c file as argument to my compiler instance and then execute it without having to make a POST call to server and execute the file there???
Originally I userstood your question to be targeting the native platform on which the browser is running:
Consider that Browsers may be running
on many different platforms,
operatinng systems and processor
architectures. Compiling C in the way
you describe might be technically
doable, but practically infeasible.
I was basing "practically infeasible" on the difficulty of supporting the plethora of widely used browser platforms.
Now I understand that you are thinking more on the lines of targeting a virtual environment. I'll amend practically infeasible to "a large amount of work".
If I understand your intent it is to run a C compiler which emits, shall we say, x86 compiled code and executes it. So to do that we need an emulation of the x86 environment in, say, JavaScript. What's more I think your intent is that the conmpiler itself execute in this environment, so that you can re-use gcc. So you'll need to emulate a file-system too. It's "obvious" that this could be done, but it really is a lot of work. Is it really worth it?
Competition code is small (I guess) even with lots of programmers the number of simultaneous compiles can't be so huge with a decent queued request system, a touch of Ajax, and a bit of back-end scaling how costly is it to support the expected population? What's the ratio of developers to back end systems?
Anyway, if I were to address this problem I'd go for taking the code for an opensource browser and melding in the gcc code. Produce a compiler/browser hybrid. Give that to the developers and tell them "Use this and get zippy compilation speeds, or use your own browser and join the queue."
You're not going to use GCC as it is written for this. AT BEST, you could accomplish something simalar if you had a compiler written in Java that targeted the JVM and could be ran as an applet. I don't know what it would take to get something like this working but, I suspect it would take a bit work to get it up and going. As far as I know nothing currently exist that does this.
Perhaps using a jsLinux in background? There the making process can run in the virtual machine. Communication could be done by extending the clipboard transfer, perhaps into multiple pipes...
I would be interested in javascript based gcc solutions, too.