The Mixed Reality Forums here are no longer being used or maintained.
There are a few other places we would like to direct you to for support, both from Microsoft and from the community.
The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.
For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality.
If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers, or in our Microsoft Tech Communities forums at https://techcommunity.microsoft.com/t5/mixed-reality/ct-p/MicrosoftMixedReality.
And always feel free to hit us up on Twitter @MxdRealityDev.
Can TDD approach be used for Developing HoloLens Applications ?
prasadl
✭
Hi, I'm new to HoloLens application development as well as unity. I want to know whether we can use Test-Driven Development(TDD) approach for developing HoloLens applications, if not what's the best development approach to be applied for developing HoloLens apps, and also I would like to know best practices as well (Assume it's an industry level Holographic app).
Thank you.
Best Answer
-
Options
utekai
✭✭✭
Yes, TDD can be used.
There is not a 'best development approach' at this point. There are many opinions.
For instance you can spend many many hours learning Unity. Or not.
You can design an app that requires the user to hold their arms out and up and tap their fingers a lot. Or not.
A few minutes of arms-up and most users don't want to do it anymore, as holding your arms out in front of you is tiring. It's a classic UI mistake Microsoft is making. But if your app is just to show the user your hologram, then it's ok. But if the user wants to do work, then don't make them hold up their arms for long periods of time to use it.
1
Answers
Yes, TDD can be used.
There is not a 'best development approach' at this point. There are many opinions.
For instance you can spend many many hours learning Unity. Or not.
You can design an app that requires the user to hold their arms out and up and tap their fingers a lot. Or not.
A few minutes of arms-up and most users don't want to do it anymore, as holding your arms out in front of you is tiring. It's a classic UI mistake Microsoft is making. But if your app is just to show the user your hologram, then it's ok. But if the user wants to do work, then don't make them hold up their arms for long periods of time to use it.
@utekai
Thanks for the reply utekai. Could you please tell me if TDD can be used, what are the steps I should follow, I mean how to write unit test classes and methods, how to do the code generation. Actually, I'm from a strong Java background. If those concepts are not relevant here let me know that as well. But I would like to develop my application peace by peace while generating the code through test cases.
Yes, letting the user hold the hand for a long time is bad. But in my case, I do have to implement some gesture activities, but I'll concern that aspect as well while developing my app. Thanks again for your answer.
"But in my case, I do have to implement some gesture activities ..."
You don't HAVE to, you're choosing to use gestures. Just be sure to use the software you create, use it as a user, and you'll understand. If your software is intended to be used for more than a few minutes at a time, arms will tire quickly.
Using voice in almost all cases ends up being a better UX than gestures. And hololens APIs include some excellent voice processing, in fact all that is needed for excellent outcomes once the developer is familiar with the APIs. Face it, most developers are uncomfortable with voice and comfortable with a mouse and choose gestures ... this is a mistake. AND A BIG ONE.
But not even Microsoft is admitting it yet, as most of the demo apps are meant to be used for only a short time, but if you use Fragments for more than a few minutes at a time, arm fatigue sets in rather quickly.
Those concepts are relevant but what TDD is really about is design before development, and you do that design by writing out some tests that need to pass.
By writing tests up front you're also explaining to yourself how the software will be used.
So you're designing ... and leaving behind design remnants that are useful for future testing and also this approach tends to minimize natural tendencies to develop too much, meaning tests would all pass but coding is still going on.
TDD has further evolved into BDD where domain language is used when describing tests, and because the tests are named according to the requirements, the tests can be written by business analysts. You end up with higher level unit tests, meaning a lot more code is tested during each test, but tests running are directly testing the functionality your system delivers, and functionality as would be described by a BA. Thus your tests end up being more valuable, less single-functiony and more use-case and user-requirements focused. You writer fewer tests and get more coverage of your code. It speeds up TDD and makes it more inclusive (meaning BAs can get involved and with domain language everyone agrees since they can understand what's being tested).
But onto unit tests specifically ... I was asking these same questions and after some time started wondering if a slightly different approach is needed for unit testing apps that run in 3D virtual space. Also I have some TDD -> BDD background and instead of writing out a couple hundred unit tests I wanted to write many fewer tests but still get good code coverage, and still be able to have a set of useful tests to let me know if something got broken.
During experimentation, I did some typical coded unit tests but found at times new code that passed written tests still was flawed and this didn't show up until viewed in 3D virtual space. This also happened a lot just with normal development, code or 2D emulator viewed outputs looked fine, but once in 3D virtual space it was easy to find flaws, this pushed me to develop right in 3D virtual space and remove lots of time consuming workflows of going from 2D environment to 3D virtual space (wrote a blog about this).
So I ended up writing tests that run not on the server after code compilation, but in 3D virtual space. Meaning the outputs being examined for passing or not passing, at least at this point, are visual outputs, so my asserts are not in code. I wanted to automate this and remove a user from being involved, but at this point, my unit tests are all visual, and I'm okay with this, because when doing something new you often break old or institutionalized patterns, and I've not yet found a right way to not use eyeballs as the final assert to pass the test.
In my case the visual unit tests also double as a help system. So when I call up help, I'm also running all my unit tests. So the tests actually test just what the system does, very precisely. And if the help a user is looking at works, then the software is working.
Overall, this approach works nicely for my app, but might not for yours. It depends on the nature of the app.
But what to take away from all this, is TDD and unit testing is fluid. There is not one way to do it, but many ways, and it depends on the nature of your application. Also, I've not seen any typical unit testing done with a unity-based projects, which adds other challenges in setting up a unit testing framework. I've started using unity less and less, just too heavyweight for most of my needs.