I have to create a Unit-Test.
But first, I´ve to get clear what to do.
There is a QtQuick2-App written and now I would like to do Unit-Tests with the GUI. What are the steps for Unit-Tests with GUI? After reading the Qt-documents, I could not create any ideas for starting with the test.
Hope somebody can help me.
Edit: I was able to run some tests, after adding tst_button.qml and tst_test.cpp to my Project (main.cpp is in comments now). Is this the right way, or should I create a new project just for the Tests? If yes, what kind of project is needed?
And the last question: Do I need to build up my MainForm for pressing buttons for example?
tst_button.qml
import QtQuick 2.4
import QtTest 1.0
Rectangle{
id: myRec
property var myMainForm: null
TestCase{
name:"ButtonClick"
when:windowShown
function test_init(){
var createMyWindow = "import QtQuick 2.0; MainForm{id:myForm}"
var myMainForm = Qt.createQmlObject(createMyWindow,myRec)
myRec.myMainForm = myMainForm
}
}
}
tst_test.cpp
#include <QtQuickTest/quicktest.h>
QUICK_TEST_MAIN(test)
Testing and Debugging lists two ways:
Qt Test (also known as testlib) - a framework for unit tests of C++ code
Qt Quick Test - a framework for unit tests of QML code
You can use Qt Test for testing Qt Quick applications, but that's generally better for when you need access to C++ API that isn't available in QML.
Do I just add a *.qml file to my project and fill it with my code? If yes, what do I have to do to start the test?
You'll first need to make the tests a separate project, unless you're planning on using qmltestrunner (I have no idea why that tool isn't documented by Qt itself).
The Running Tests section of Qt Quick Test's documentation details how to get a test up and running.
I was able to run some tests, after adding tst_button.qml and tst_test.cpp to my Project (main.cpp is in comments now). Is this the right way, or should I create a new project just for the Tests?
If your application is pure QML and only intended to be run with qmlscene, for example, then doing it that way is fine. However, if you intend to deploy/ship your application, you'll probably need to have an executable, which means making separate projects for the application and the tests.
If yes, what kind of project is needed?
You could have a SUBDIRS project, so that your tests and the application itself can all be opened at once in Qt Creator. Something like this:
myapp.pro
app/
main.cpp
app.pro
resources.qrc
main.qml
tests/
tests.pro
data/
tst_stuff.qml
And the last question: Do I need to build up my MainForm for pressing buttons for example?
No. The .ui feature is just a format that allows Qt Creator to enforce certain constraints to make it easier to design Qt Quick UIs with Qt Quick Designer. MainForm.ui.qml is therefore just a convenience. If you already have an existing component in QML, you can create instances of that and test it.
Related
Oh, Xcode!
I'm stymied. If I create a Mac OS Cocoa app, I get a unit test target for free. But I want to write a command line tool (or even a library that I can link into a command line tool) and write some unit tests against it. I'll be darned if I can figure it out.
I've gotten far enough that I have a command line target, and a test target. I can "#testable import" my commnd line module and use the code in the test code with no errors in Xcode. However, as soon as I try to run my test (Cmd-U), I get a link error. None of the classes in the main module can be linked. What?
I've been messing with this for hours, and the Great Google has been no help. (I'm using Xcode 7, and Xcode 6 seems very different.) Can anyone help me?
Thanks.
So far the only solution I've found for this problem is to manually add all the files containing code that you want to test to unit test target manually:
This is something you wouldn't do when testing an application target. I think the fact that the command line target cannot be selected as the test host for a unit test target might be related with this issue:
Another option you have, which might require a bit more work, is to define all your logic into a Framework, and write the command line app as a consumer of the APIs it provides.
This way you can easily unit test the framework the usual way, and then write integration tests for the command line app in the form of scripts that call it and assert the results.
After struggling with this here is the solution that worked for me:
Step 1: Add a testing bundle. Editor > Add Target, Cocoa Testing Bundle
Step 2: Edit the scheme. Product > Scheme > Edit Scheme. Select Test, click +. Under “Choose targets to test as part of this scheme”, select your test target.
Step 3: Try with you simple test
There are cases when adding the same file to both utility and the test target is not possible (some kind of loops resulting in redefinitions).
However, it's possible to create an additional application target, add all files of the utility except for main.swift to the app, and then use this app as a hosting app for the tests (and also enable "Allow testing Host Application APIs checkbox).
I am trying to unit test a command line tool written for Mac OS.
When I first create the project, XCode does not generate a tests group in the project navigator. When I try to add a new test target, it doesn't give me the option to specify my target as the "Target to be Tested".
My question is this: is it even possible to use XCTest for a Command Line Tool project? Or is it just considered trivial to do so by virtue of the fact that I could just run it from the command line? I could understand that reasoning, but there is internal functionality I'd really like to test.
I'm not sure what version of Xcode you are using, but I ran into a similar problem using the templates in Xcode Version 6.2 (6C131e). That said, I was able to get XCTests to work with a Command Line Tool project. The solution was to ignore the "Target to be Tested" field during creation and instead add the Test target to the main scheme after creating it:
Go to Manage Schemes. You should see your main Target’s scheme and a
newly created test scheme.
Select you main scheme and go to Edit.
Select the Test action and add your new Test target to the tests
list using the “+” in the Test action detail panel.
From there you should be able to run the tests using cmd-U.
In Xcode 8.2, I was only able to run unit tests in a command line app by adding a unit test target from the Test Navigator, then editing the testing scheme to include that new test target under the "tests" list, and manually adding testable source files to the test target from the "target membership" section of the File Inspector pane.
(Adding a unit test target from the project "add target" screen wouldn't link properly with XCTest framework, even after adding the framework to build phases.)
Following the Apple doc directions for adding a unit test target from the Test Navigator pane looks like this:
Note:
In the Unit Test Target setup, the "target to be tested" dropdown still won't select the command line tool. Leave this option as "None".
For adding unit test target (XCTest) for Mac OS Command Line project which has(main.swift and other swift files), to make this work,
1.Add UnitTests target to scheme by editing in manage schemes
2.Make your functions and classes has PUBLIC access
This solved my linking errors. Hope it helps for you guys as well
I've written a small library as a Qt project using Qt Creator, now I want to create a small GUI application that can be used to test it as part of the development process, so it could be like this:
Project root at:
~/code/mylib
Library project and associated code:
~/code/mylib/corelib/corelib.pro
GUI test tool and associated code:
~/code/mylib/libgui/guitool.pro
So far I've only been able to make things work by setting up LIBS+= in the GUI project's .pro file, manually building the library, copying the library's .a file to the GUI directory, and rebuilding the GUI project. A tedious process. Worse: I'm developing the project now on Linux but need to make it build on Linux and Windows, and this manual build style will probably make that harder.
I suppose there's a way to do make Qt Creator aware of the relationships between the projects, so for example building the GUI tool in debug mode use the debug version of the library, or making changes to the corelib would necessitate a build in the GUI, building on some OS would use the libraries OS-configuration...etc
This kind of thing is a couple of clicks away in Eclipse and Visual Studio, but I can't seem to get it working in QtCreator. I've tried "Add library->Internal library" and creating a 'subdirs' project but neither seems to work. I feel it's probably a simple step that I'm missing somewhere, any help?
Try again to use subdirs feature. It have own wizard "Project with subdirectories", but in your case it's easier to write it manually (in example I've added "ordered" to ensure that order of compilation is always correct).
TEMPLATE = subdirs
CONFIG += ordered
SUBDIRS = corelib guitool
Than you can add libary to your GUI application with wizard (accessible from context menu inside .pro).
I use VS2010 for C++ development, and I often end up doing work in some dll project and after everything compiles nicely I would like to try to run dummy data on some classes, but ofc the fact that it is a dll and not an exe with main makes that a no go. So is there a simple way to do what I want, or Im cursed till eternity to c/p parts of a big project into small testing one?
Ofc changing the type of the project also works, but I would like to have some almost like iteractive shell way of testing functions.
I know this isn't a library or anything, but if you want to run the dll on windows simply without framing it into anything, or writing a script, you can use rundll32.exe within windows. It allows you to run any of the exported functions in the dll. The syntax should be similiar to:
rundll32.exe PathAndNameofDll,exportedFunctionName [ArgsToTheExportedFunction]
http://best-windows.vlaurie.com/rundll32.html -- is a good simple still relevant tutorial on how to use this binary. Its got some cool tricks in there that may surprise you.
If you are wondering about a 64-bit version, it has the same name (seriously microsoft?) check it out here:
rundll32.exe equivalent for 64-bit DLLs
Furthermore, if you wanted to go low level, you could in theory utilize OllyDbg which comes with a DLL loader for running DLL's you want to debug (in assembly), which you can do the same type of stuff in (call exported functions and pass args) but the debugger is more for reverse engineering than code debugging.
I think you have basically two options.
First, is to use some sort of unit tests on the function. For C++ you can find a variety of implementations, for one take a look at CppUnit
The second option is to open the DLL, get the function via the Win32API and call it that way (this would still qualify as unit testing on some level). You could generalize this approach somewhat by creating an executable that does the above parametrized with the required information (e.g. dll path, function name) to achieve the "interactive shell" you mentioned -- if you decide to take this path, you can check out this CodeProject article on loading DLLs from C++
Besides using unit tests as provided by CppUnit, you can still write your own
small testing framework. That way you can setup your Dll projects as needed,
load it, link it, whatever you want and prove it with some simple data as
you like.
This is valueable if you have many Dlls that depend on each other to do a certain job.
(legacy Dlls projects in C++ tend to be hardly testable in my experience).
Having done some frame application, you can also inspect the possibilities that
CppUnit will give you and combine it with your test frame.
That way you will end up with a good set of automated test, which still are
valueable unit tests. It is somewhat hard starting to make unit tests if
a project already has a certain size. Having your own framework will let you
write tests whenever you make some change to a dll. Just insert it into your
framework, test what you expect it to do and enhance your frame more and more.
The basic idea is to separate the test, the testrunner, the testdata and the asserts
to be made.
I’m using python + ctypes to build quick testing routines for my DLL applications.
If you are using the extended attribute syntax, will be easy for you.
Google for Python + ctypes + test unit and you will find several examples.
I would recommend Window Powershell commandlets.
If you look at the article here - http://msdn.microsoft.com/en-us/magazine/cc163430.aspx you can see how easy it is to set up. Of course this article is mostly about testing C# code, but you can see how they talk about also being able to load any COM enabled DLL in the same way.
Here you can see how to load a COM assembly - http://blogs.technet.com/b/heyscriptingguy/archive/2009/01/26/how-do-i-use-windows-powershell-to-work-with-junk-e-mail-in-office-outlook.aspx
EDIT: I know a very successful storage virtualization software company that uses Powershell extensively to test both it's managaged and unmanaged (drivers) code.
I have CLI/MFC application and I would like to begin to learn how to unit test with it. I have VS2008 Pro. If possible, I would like to use the built in unit testing. Thanks for your input!
I've had success with both CPPUnit and Google Test. For either you have to do a bit of work to get the test results to integrate back into Studio. The granularity of the results you want directly affects how much work. Do you want a pass/fail for the whole test set, or individual results? The former is a simple msbuild task, the latter requires outputting the result set to XML, massaging that with a transform, then pulling it back in.
We use Gallio & MbUnit to test our MFC & C++/CLI application. Simply write the tests in C++/CLI then you can test both managed and unmanged code in a single framework. We also use NMock2 for mocking the managed code.
If you have Team Test edition, you can use it to test C++/CLI applications and libraries. See here.