1.Does watchOS (as of watchOS 4.3) currently support unit or UI testing? There is no UI Test Case Class file and Unit Test Case Class file in the watchOS file.
2.If watchOS supports unit testing, can we place the Unit Test Case file of watchOS in the iOS Unit Test Case file?
This has been added to Xcode 12.5 otherwise your best bet is modularize and refactor your code into Swift Packages and test them that way. There's a lot of code in your application which doesn't require watchOS (unless it's UI Testing of course).
Here's a great post by Jason Zurita about he does this and it's the approach I use as well:
https://jasonzurita.com/automated-testing-for-watchos-apps/
I also explain some of the process here with my app Heartwitch:
https://youtu.be/fzLkHAku1mc?t=1723
Related
I have some legacy C++ that I call using an Objective C++ bridge from a Swift iOS app.
I first built a simple test app (basically just the C++ call with limited UX around it). In this test app the C++ takes between 0.4 and 1.4 seconds to complete, as measured naively using this pattern:
let startedAt:NSDate = NSDate()
self.callOutToCPlusPlus(loads:of, passedIn:values)
print("CPlusPlus done in \(NSDate().timeIntervalSinceDate(startedAt)) seconds")
Now I have added the same code used in the test app to the full app where it takes 3.5 seconds. How do I diagnose the slow down?
A few ideas:
1) Is the legacy code built as part of the Xcode project? If so, you may be able to use Xcode's profiling capabilities to see where the slowdown is.
2) Do you use the same optimization level in your test and full apps?
3) Do you pass the same data to the legacy code in both apps?
Hopefully this helps.
I am a graduate student and I am trying to propose a project for a advanced testing course.
Since I am a embedded guy, I do want to test something challenging related to embedded systems.
uC/OS-II is an very nice open source light-weighted OS for embedded systems. So I want to propose the testing for it for my course project.
But I don't know the feasibility of testing uC/OS. Is it doable?
I am using Blackfin and SHARC (are from Analog Devices) now and they are compatible with uC/OS (said on the uC/OS website).
In terms of testing tools, I think CUnit might work. Also we have a unit testing tool call EmbeddedUnit, which runs on VDSP (development environment for Analog Devices processors).
I have no experience with uC/OS, but my understanding is we should compile it and then include the .obj files and the header files into the project then we can use and test the functions in uC/OS.
Am I right?
Is it doable? Yes it is. We had a project that needed to be portable to many different environments uCos-II, Linux and VxWorks. In order to do that we wrote as simple abstraction layer that gave us a common API on all platforms to the OS features we chose to have enabled. We then wrote a Unit Test to test the abstraction layer, and had a unit test case for each OS feature we wanted to test (Msg Queues, Semaphores, Event Flags etc). We used that to verify our abstraction layer was functional and working on all 3 host environments.
uCos-II is delivered as very clean c-code that can easily be used in any number of tools such as code coverage etc.
Good luck.
I am new to Qt and unit testing. I have gone through the documentation and example of unit testing, but i couldnt figure out how to use the test scenario's in an application.
For eg. In the documentation a QLineEdit is created and then the value is checked with a specific value.
void testGUI()
{
QLineEdit lineEdit;
QTest::keyClicks(&lineEdit, "Hello");
QCOMPARE(lineEdit.text(),QString("Hello"));
}
When i run the program all the result is shown in the console.
But how can i check if i have a QLineEdit and a QPushButton in a QMainWindow form.
How to do GUI Testing ?
You seem to be looking into GUI unit-testing.
Here you go: How can I unit test a GUI?
Unit testing usually doesn't include the user interface. Unit testing should be the low level, testing of each unit (class/component). Then integration testing tests the units working together to accomplish something. Sometimes mock objects are employed here to act as stand ins for other components, so verify the behaviour is what you'd expect.
After you have unit testing and integration testing handled, the UI testing should be pretty strait forward. For a Qt project, the cross platform gui testing framework from froglogic called squish might be your best bet. However it is a paid product, and if you don't need its cross platform nature, you may be able to get away with some free tools. Most come down to running your application under some sort of instrumentation, and then it replaying your interactions with the user interface, and verifying the values of text fields etc.
Anyway I believe XCode and Visual Studio provide some basic ui unit testing tools. Their is also a wikipedia article here.
What tools are generally used for unit testing and especially continuous integration for embedded systems?
I am especially thinking that you usually have to cross-compile and deploy, and also that you can't easily visualize the target platform. Also it can be difficult to run test-code and frameworks.
What could I use too alleviate these difficulties?
(I think it should be some kind of dual targeting, where the build server runs its tests on a easier target)
For unit testing, take a look at Unity.
http://sourceforge.net/apps/trac/unity/wiki
It is a really lightweight test harness (2 x .h and 1 x .c file) supported by Ruby scripts. We have been using in an embedded ARM7 target system for unit testing (redirecting test reporting over a serial port).
It is also supported by CMock for (surprise, surprise) Mocking. Even though not extensive, the great thing about these is they are so easy to use.
Regarding CI, then Hudson (now Jenkins) is very good if you're Linux based.
Also look at CppUTest and check out James Grenning's book "TDD for Embedded C" at http://renaissancesoftware.net/
At work I use the embUnit framework:
http://embunit.sourceforge.net/embunit/index.html
The nice thing about this framework is, that it's lean. It does not require any external libraries (not even libc). You can hook your own output function with ease so if you work on a system where the only connection to the outside world is jtag or an UART, then embUnit will still work.
I have used RCUNIT and CANTATA++ for unit testing embedded code on the PC. Any Nunit should easily integrate into any continuous test platform. We found it an lot easier to just simulate the hardware on the PC and only test on the target during final integration.
Hardware interface abstraction is crucial for unit testing embedded code on the PC. This works well with continuous integration since it is run on a pc with just the hardware access simulated. With a little effort we could test 95% of the code on a PC for continues integration.
You could also look at these questions:
Unit Testing C Code
Testing Frameworks for C
Unit Testing Embedded Software
I've seen C(pp)unit used on a system that let you launch to the target via JTAG.
Helps to have console comms etc sorted.
But it can work.
I'm working on an open-source tool for that, that is either a minimal test or can provide detailed information when run through the debugger.
we have one main application, which executes up to 5 different exes. These exes run independently and communicate with each other via UDP. Changing this architecture is not planned at the moment.
We want to migrate this whole thing from VS6 to VS2008.
I'm thinking about adding unit tests to make sure that after migration everything still works. Right now, there is not a single unit test.
So now I have a couple of questions:
Which unit test framework works fine with VS6 and VS2008? CppUnit seems to work with both compilers, at least I got it running.
How do I implement the unit tests in the above mentioned architecture? I see a problem that I have executables and no libraries, so it seems to be a bit difficult for me at that point
Is creating the unit tests for both platforms worth the effort or do you have a simpler suggestion?
Suggestions, best practices, new ideas welcome :)
Thanks
If they communicate via UDP and you want to make sure the integration between pieces works now and later, you could write automated tests against the UDP interfaces in MSTest or NUnit in VS2008.
Write the tests in VS2008 and send input/verify output of the interfaces to the the .exe applications. Then, when you switch to .NET, just point your tests at the new endpoint for the .NET .exe and run them to verify all input and output are the same.
I think you would get more bang for your time to write the unit tests exclusively for the new app, but write tests against the external UDP interfaces to verify the migration was successful.
If you are willing to consider each of the executables as as 'module', then there is a way to introduce tests without being too invasive.
This would create modules that will be a bit large for many people to be comfortable with (typical sizes when people talk about modules is a class or a source file), but your communication mechanism provides a nice way to hook in the tests.
With the architecture that you have and the fact that you don't have an existing test harness for the code, I would write a test harness that can communicate with each of the executables in isolation, using the UDP interfaces.
When executing the tests, only one executable is running (besides the test code). The test code simulates the other executables by listening on their respective UDP ports and providing responses as the testcase requires. The testcase also stimulates the executable under test by sending UDP requests to it. If there is also a GUI/TUI involved, it might be needed that parts of the tests are executed manually.