It's easy to create unit tests for Windows Phone apps (8.0/8.1) that run on the emulator.
Now, it would be great to be able to 'remote control' the emulator from inside such a test (e.g. changing the orientation or the location on the fly).
Does anyone know a way how to do this (or has at least an idea about the way to go)?
EDIT:
I'm using the standard Phone Unit Test project template (which uses MSTest) in C#.
Your question is very poor, you have to provide more information at least about what language, Test framework, tool are you using for your tests?
My article about Custom Mobile test framework maybe useful to you. Feel free to reuse what you find helpful or to ask questions.
Related
So, testing with Sitecore. It's a special topic and I've found allot of reading material regarding it already. (Sitecore Development Chapter 8, Alistair Deneys blog, NextDigital blog, iStern blog,...) but in most of these cases they're going with NUnit and custom test runners etc... The most useful (to me in my context) this far was the iStern blog for mocking out Sitecore using Microsoft Fakes. But is this really the way to go?
I'm surprised that with Hedgehog TDS system to integrate so deeply with TFS and be able to do CI in Sitecore development that there isn't more on how to utilize this system for setting up solid testing executed by TFS (yet).
We're gearing up for a large new project now that uses Sitecore to handle front-end user interaction where the data being used is 95% behind a WCF service. So this part can be easily tested and TDD developed. It's the last 5% (which sadly includes like the highest business value, being online payments) that resides within Sitecore that needs to be tested. Can we ever have enough intimate knowledge of sitecore to mock it out? I'd be inclined to think not... if so, how then do we run conclusive tests on our TFS CI build against sitecore?
Last but not least I get the feeling that the information currently to be found is getting a bit out of date perhaps (maily seeing the remarks on the NextDigital blog), does Sitecore 7 open new ways to tackle this issue?
For those who'd see this more as a philosophical rather then a technical question: There can only be one answer to this and that is a technical accurate definition of a method of using the Microsoft test framework that is capable of running in the TFS CI environment to test code written for Sitecore.
Is Microsoft Fakes the way to go? In my opinion, no. Microsoft fakes allows you to test code that is not designed to be testable. If you design you solution properly, a standard mocking framework should be sufficient.
Can we ever have enough intimate knowledge of sitecore to mock it out? This is kind of a trick question. Unless a third-party library was specifically designed for it and is something that you would consider a "stable dependency", you shouldn't try to mock it. Instead, wrap it with your own classes and abstractions and mock those.
Take a look at Synthesis and Glass Mapper. They are object-mapping frameworks that allow you to map Sitecore items to interfaces while maintaining page editor support. Glass, in particular has a wrapper around Sitecore.Context that can be mocked. Synthesis is supposed to be pretty testable as well, but I haven't tried it yet.
Using one of those mapping frameworks and a good SOLID design, you should be able to make most of your code testable. Just remember that the classes on the edges of your solution should be simple enough to not require testing.
I was in the exact same situation as you, IvanL, a few weeks ago. I wanted to test some of my business logic running against Sitecore 7 without a mocking framework. I managed to do it, but only in a very specific scenario. Unfortunately, I haven't published my prototype solution or the slides explaining it yet, but I'll explain the basics of what I did.
In Sitecore 7, the move towards querying against the index with the Sitecore.ContentSearch namespace and using LINQ opened up a way for me to very easily unit test with fake index data.
There are some unit test examples out there, as you've seen, that use mocking frameworks. However, the classes they mock are actually quite simple to fake out yourself. If you implement ISearchIndex, you really only need to implement the CreateSearchContext method in order to start returning an IQueryable to work with in your tests.
To implement CreateSearchContext, you will likely need to create a fake provider search context implementation that will do the GetQueryable implementation.
Once you have those two classes set up, you've essentially got your 'index' covered. Add a property onto it where you can set the data collection from the unit test and then make sure the context returns that data collection.
That will let you build up a fake index with whatever data POCOs you want, and then pass that through to your standard provider implementations that are running your business data.
The big thing to remember is that this only works for any code you may be writing that will use the new Sitecore 7 way of using LINQ and the IQueryable implementation. Older style code that is running using the Sitecore.Data.Item API still works the way it used to, and has the same limitations as before.
Update: The prototype I mentioned is now available for download: http://blog.nonlinearcreations.com/2014/02/sitecore-7-developers-quest-successful-unit-testing/
I have developed a project in c++ using eclipse and my OS is mac. I need to do automated unit testing and could anyone suggest a framework which is simple and easy to develop the test cases.
thanks
Google Test - What I really like is that it has easy to understand documentation.
That's what I've tried and it works well.
You should really also read this page.
Finally, there is this comparison between testing frameworks. It does not have Google Test though.
Rule of thumb: Keep it simple and don't speculate. Don't choose a framework because it has features you think you will need. Choose a framework that works for you, is under active development and is also used by a lot of others.
Best c++ unittest system around is http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page
By backend I mean software systems that consume data, process files or communicate using machine interfaces (REST, SOAP, CORBA, etc...). No fancy web or UI testing is necessary. I have in mind Cucumber and Robotframework but I don't know how well suited they are in the task at hand.
There isn't an easy answer to this question.
Sounds like you got your domain right... because if you were trying to test UI/Web components acceptance testing frameworks make not be the right tool for the job.
You have a few options
SpecFlow
Cucumber
StoryTeller
FitNesse
mSpec
a few others.
I'm partial to StoryTeller & mSpec.. but each of these tools have their pros/cons.
Questions you should be asking yourself (and your team are)
Who is going to be writing/maintaining the tests?
Are self documenting acceptance tests provide value for your organization?
Which technology would integrate most easily with your current build process?
I have used Cucumber to test a batch application written in perl and plsql, an informatica transformation, and am currently using it to test a telephony ivr/queueing system. Ruby provided the gems I needed to drive the system and it was very easy for the testers to learn the language/syntax.
If it comes to Robot Framework I have an experience with bad support in Intellij for this. I'm using IntelliBot plugin. In many cases you will know your mistake like wrong syntax, cannot find keyword etc. late in test runtime.
Problems with finding imported libraries, no debug, no simple refactor like rename keyword across a project.
I'd like to run my Java Card applications in some kind of emulated/simulated environment to be able to run JUnit (or any other unit test framework) tests on them. Does anyone know of such a tool? I'd prefer some open source project.
Special for this purpose our team developed jCardSim: open-source JavaCard Simulator - http://code.google.com/p/jcardsim/.
//1. create simulator
Simulator simulator = new Simulator();
//2. install applet
simulator.installApplet(appletAID, HelloWorldApplet.class);
//3. select applet
simulator.selectApplet(appletAID);
//4. send apdu
ResponseAPDU response = simulator.transmitCommand(new CommandAPDU(0x01, 0x01, 0x00, 0x00));
//5. check response
assertEquals(0x9000, response.getSW());
Unit-test example : http://code.google.com/p/jcardsim/source/browse/trunk/src/test/java/com/licel/jcardsim/base/SimulatorTest.java
It's fully emulate the real NXP-chip JavaCard. Try use it.
Any comments and ideas are welcome! We will be grateful if you share link to the project!
Note that one method of doing this is to create JUnit tests in Java SE, and use APDU's to communicate with the classes in Java Card. Obviously this is not the same as directly testing classes in Java Card, but beggars cannot be choosers. In general you would need to create an Applet that does some conversions for you. This is the method that is used in the jCardSim answer from Mikhail - it could of course be used on a real card too, but you would lose any code coverage and - possibly - debugging options.
Another method (that I've got a proprietary, working solution for) is to implement unit tests on the card and call them from a JUnit test framework from Java SE. This is a lot of work; I've had to generate my own List implementation for this to work. It was worth it though; it let me use Java Card defined objects and types from within Java Card. There is no open source alternative for this as far as I know.
It could be an option to add a JUnit test framework to jCardSim and test classes directly, as the complete JRE is available during compilation of the Applet. Note that jCardSim is not a fully functioning Java Card yet (e.g. no reset of memory as specified in the API, no transaction support etc. etc.) so be aware of this when testing Java Card specific code.
Don't know the Java Card, however, at first glance, it seems not much different than any other JavaME platforms (by different I mean comparing them to e.g. J2SE). As such you may use any ordinary e.g. JUnit test environment with Eclipse/Netbeans to make development little bit easier. You may need powermock to mock some platform specific stuff. Hope this helps.
One tip for Netbeans: you may consider separate project for tests (that depends on your application project). In that case you can have your UTs coded with the power of latest Java toys.
Java card applets are simple pieces of Java code. So, JUnit is fine. Test them like you test regular java classes.
But the problem is that I never saw java implementations of classes in javacard.* and javacardx.* packages. If you will get them - the problem is solved.
If you want to test how applet itself works (APDU send/receive), then there is cref.exe in the Java Card SDK. It's a javacard emulator.
I've recently started work on the Compact Framework and I was wondering if anyone had some recommendations for unit testing beyond what's in VS 2008. MSTest is ok, but debugging the tests is a nightmare and the test runner is so slow.
I see that NUnitLite on codeplex is an option, but it doesn't look very active; it's also in the roadmap for NUnit 3.0, but who knows when that will come out. Has anyone had any success with it?
What we've done that really improves our efficiency and quality is to multi target our mobile application. That is to say with a very little bit of creativity and a few conditional compile tags and custom project configurations it is possible to build a version of your mobile application that also runs on the desktop.
If you put all your business logic you need tested in a separate project/assembly then this layer can be very effectively tested using any of the desktop tools you are already familiar with.
We use NUnitLite, although I think we did have had to add some code to it in order for it to work.
One of the problems we found is that if you are using parts of the platform that only exist in CF, then you can only run those tests in NUnitLite on an emulator or Windows Mobile device, which makes it hard to run the tests as part of an integrated build process. We got round this by added a new test attribute allowing you to disable the tests what would only run on the CF (typically these would be p/invoking out to some windows mobile only dll).