please guide me how to test a monitoring tool?
Due to the nature of the project (a program that monitor another target program), we cannot expect the input (activity of target program) and hence what is the best way to test it?
I don't know exactly how your monitoring tool is working, but I think that some how it communicates with some 'target' applications, retrieve data from them and displays a report.
I think that your problem is that you cannot control the input to your monitoring tool, in order to test that it displays correct data, because that input depends on your target apps.
My suggestion is to create a Mock application. This app must have the same interface with your real target app so your tool can communicate with it. Of course, the implementation must be different. Implement it with that way, so that every parameter is checked by your tool will be configurable to you. So, you will be able to know which will be the input to your tool.
Related
I have a UWP Class Library project (written in C#) with some useful utility classes and functions. I want to create a script that uses these classes and functions and runs a few times a day automatically. What is the best way to achieve this?
Should I create an app? If so how can I make it run a few times a day?
Should I create a classic console exe program and run it using a script? If yes, can console apps use UWP class libraries?
Should I create a Windows Runtime Component with background task?
Or some other solution?
Assuming that you're definition of "scripting" can be stretched to mean "run an app" there's lots you can do. If you want something that will be seen as a more traditional script then the best you can do is compile the code in a standard .Net class library (not a UWP one) and then call it from a PowerShell script. If you can run apps then there are a few options and the most appropriate will probably depend on the device they're running on, how often you want them to run, and what they actually do.
As you're talking about a UWP app we should allow for it running on different "device families". The easiest way to run on different devices (desktop & phone, etc.) is to have a periodic background task. At time intervals defined by you it will try and run. Subject to connectivity, power, etc.
Because you said a console app was an option then you're probably really only interested in a desktop/PC environment. That's where there's the most options.
Firstly, if your code uses UWP/Win10 specific APIs then compiling into a console app probably isn't possible without changing the code. I do many things like you describe in the question and use console apps for this as I find them the simplest to work with.
If you're going to change code, consider moving to using Portable Class Libraries as you'll then be able to link to that code from many different types of app--including traditional desktop and UWP apps.
I'd avoid creating a runtime component unless you really need to as there are lots of potential gotchas.
You can run any app from the Task Scheduler but launching UWP apps is tricky.
You can launch a regular app or script by setting the action of the task to be the exe. (or the exe and passing the script file as a parameter.)
Apps from the store don't have an EXE you can just launch so you need to do a bit more. They can only be launched by the Windows Shell. But, fortunately, there's a way to do this. Have your task start explorer.exe (You'll find it in C:\Windows) and then add the argument shell:AppsFolder\[app-PFN]!App.
Where [app-PFN] is the Product Family Name of the app. You can find the values of all the installed apps on your machine by looking at "C:\Users[username]\AppData\Local\Packages\"
So, you can use this to launch the store app.
shell:AppsFolder\Microsoft.WindowsStore_8wekyb3d8bbwe!App
TLDR; is it possible to send/receive objects between an app and a 3rd party launch agent?
I'm writing an extension for an existing app (A). It's packaged and I do not have access to the source - but I can write simple plug-ins that can do some basic Cocoa and host a UI. Read: very limited options.
Ideally, what I'd like to do is have the plugin in app (A) message an external service (B) [sending objects], have (B) do some heavy lifting, then respond back to (A) so the UI can update.
I've been reading up on Launch Agents and they look promising, but I noted the examples all use basic types - no objects. I found one post discussing how to use Distributed Objects, but that's about it. It looks great, but what worries me is I'm not seeing a whole lot of current information on DO and I can't tell if it's something Apple will continue to support going forward.
Does anyone have any suggestions on options for a scenario like this? Maybe I'm just approaching this the wrong way?
Another option is I just completely split this out - write a separate full app and have (A) open it up with AppleScript. The UX wouldn't be as nice, but it would also work.
Thank you,
Eric
NOTE: I can't use NSTask. Or at least I've failed utterly to get it to work in this specific situation. Due to issues with app (A) it breaks when some of the methods run within the process. If I could somehow spawn NSTask so it was executing completely outside of (A) that might be an option. Which is actually what prompted me to look at Launch Agents...
I need to automate testing of my windows mobile application. My application does not have any UI. So, normal testing tools which works with random key strokes and mouse clicks will not work here. Are there any tools available for windows mobile to test only background processing?
You have a couple of options depending on what level of testing you want.
Integrated Test
An integrated test aims to test the application in the real world. Therefore you would create all of the "real" things and write code to specifically test to see if your conditions are met. I would believe however, if you're trying to test GPS then this would not be practical. As someone would actually have to move the device around.
Unit Test by mocking
I've done this before for GPS testing. The idea is that you SANDBOX the object being tested. You ensure that all external references (e.g. anything that isn't the object) are interfaces. You then MOCK these interfaces with "test-only" implementations.
For example I worked on a GPS test where we used an interface called: INmeaInterpreter to fire certain events which would be picked up by a class named PositioningService.
The default implementation was a 3rd party component.
However as INmeaInterpreter was an interface we could create an implementation that instead of using the REAL data uses (for example) an NMEA file to read from. This enabled us to test how the PositioningService worked in certain (and sometimes strange) scenarios.
I would then suggest mocking the other external references. The call to the database can just be a dummy object with a counter for the database call that is incremented if it is called. You could then write a test with an NMEA file that should result in a database call and then at the end of the unit test check that dummy object to see if that call occurred.
We did all the above with horrible MSTest but you could use any testing framework (I recommend NUnit). I'm not sure if there are options to specifically test on the device. We ran all of our tests on desktop as we'd split the code nicely so that device specific code was isolated and could easily be replaced with Desktop equivalents.
Obviously the only problem with unit tests is that they dont test the hardware.
I would recommend (depending on the size of the project and the team) to do BOTH types of testing but to place the larger emphasis on the unit tests (as they are easier to run/manage).
I'm looking for a code coverage tool that I can use with a BlackBerry application. I'm using J2ME-Unit for Unit Testing and I want to see how much of my code is being covered by my tests.
I've tried using Cobertura for J2ME but after days of wrestling with it I failed to get any results from it. (I believe that the instrumentation is un-done by the RAPC compilation). And despite this message, the project seems to be dead.
I've looked at JInjector but the project seems very incomplete. There is little (if any) documentation and although it claims to be able to work with BlackBerry projects, I haven't seen any places where it has been used for that purpose. I've played with the project quite a bit but to no avail.
I've also tried the "Coverage" view in the BlackBerry JDE, even though I use Eclipse for development. The view stays permanently blank, regardless of clicking "Refresh" and running the application from the JDE.
I've looked at most of the tools on this SO thread, but they won't work with J2ME/BlackBerry projects.
Has anyone had any success with any code coverage tools on the BlackBerry? If so, what tools have you used? How have you used them?
If anyone has managed to get JInjector or Cobertura for J2ME to work with a BlackBerry project, what did you have to do to get it working?
I can't speak for Coberatura or JInjector, because I don't know how they collect test coverage probe data.
What is
critical is how this data is captured (does it need Java runtime support only available in standard Java VMs?) and how it is exported to the test coverage display/report generation tools.
Our SD Java Test Coverage tool instruments your source code; at runtime this produces an array of native Java booleans representing the coverage data, without need for any special VM support. Normally, this array is exported directly to a file, used by the test coverage display mechanism, by a TCVDump method provided with the test coverage tool, as your application exits.
Java (and other programming langauges used) in embedded systems often requires custom methods to extract the test coverage data. You might need to code a special dump procedure (in Java) to write out that boolean array to an accessible place. Our experience with building such custom dump procedures is that they are generally pretty simple (a few dozen lines); the real trick is deciding how/where to put the data, so that it can be easily moved to the target file. Mostly this is just a peculiar pair of copies, the first of which copies the boolean array to some staging location, and the second which writes the staged data into the destination file. (The standard TCVdump method is provided in source form to enable this kind of customization).
While I haven't specifically looked at BlackBerry, if you can write the data anywhere, you can pretty much be assured you can achieve this. We've had success with other embedded hand-set systems, such as Symbian, doing this.
If you want a complete overview of how to generally instrument code for test coverage following this strategy, see this paper: Branch Coverage for Arbitrary Languages Made Easy
I was actively involved with JInjector while working at Google. We were able to use it to successfully obtain code coverage for Blackberry applications. The application lifecycle for Balckberry apps is less predictable than J2ME and we found we had to tweak the application code to ensure the coverage data was gathered. I didn't personally work on the blackberry apps, several other engineers did. I'd hoped we'd create an example blackberry application and make it available on the jinjector site, but events and life got in the way.
If you would be willing to provide a sample blackberry apps with some unit tests, I'd be willing to spend a few hours trying to help you get the code coverage working. I'm not actively working with either J2ME or Blackberry (I'm currently working on Android apps when I have time to experiment with mobile) so I'm quite rusty. I have a day job that doesn't involve much mobile test automation, however I continue to work on ways to improve the test automation for mobile apps e.g. http://code.google.com/p/mwta/downloads/list for Android Test Automation.
I'm julianharty at gmail.com
I have recently come across a situation where code is dynamically loading some libraries, wiring them up, then calling what is termed the "application entry point" (one of the libraries must implement IApplication.Run()).
Is this a valid "Appliation entry point"?
I would always have considered the application entry point to be before the loading of the libraries and found the IApplication.Run() being called after a considerable amount of work slightly misleading.
The terms application and system are terms that are so widely and diversely used that you need to agree what they mean upfront with your conversation partner. E.g. sometimes an application is something with a UI, and a system is 'UI-less'. In general it's just a case of you say potato, I say potato.
As for the example you use: that's just what a runtime (e.g. .NET or java) does: loading a set of libraries and calling the application entry point, i.e. the "main" method.
So in your case, the code loading the libraries is doing just the same, and probably calling a method on an interface, you could then consider the loading code to be the runtime for that application. It's just a matter of perspective.
The term "application" can mean whatever you want it to mean. "Application" merely means a collection of resources (libraries, code, images, etc) that work together to help you solve a problem.
So to answer your question, yes, it's a valid use of the term 'application'.
Application on its own means actually nothing. It is often used by people to talk about computer programs that provide some value to the user. A more correct term is application software and this has the following definition:
Application software is a subclass of
computer software that employs the
capabilities of a computer directly
and thoroughly to a task that the user
wishes to perform. This should be
contrasted with system software which
is involved in integrating a
computer's various capabilities, but
typically does not directly apply them
in the performance of tasks that
benefit the user. In this context the
term application refers to both the
application software and its
implementation.
And since application really means application software, and software is any piece of code that performs any kind of task on a computer, I'd say also a library can be an application.
Most terms are of artificial nature anyway. Is a plugin no application? Is the flash plugin of your browser no application? People say no, it's just a plugin. Why? Because it can't run on it's own, it needs to be loaded into a real process. But there is no definition saying only things that "can run on their own" are applications. Same holds true for a library. The core application could just be an empty container and all logic and functionality, even the interaction with the user, could be performed by plugins or libraries, in which case that would be more an application than the empty container that just provides some context for the application to run. Compare this to Java. A Java application can't run on it's own, it must run within a Java Virtual Machine (JVM), does that mean the JVM is the application and the Java Code is just... well what? Isn't the Java code the real application and the JVM just an empty runtime environment that provides nothing to the end user without the loaded Java code?
I think in this context "application entry point" means "the point at which the application (your code) enters the library".
I think probably what you're referring to is the main() function in C/C++ code or WinMain in a Windows app. That is, it's the point where execution is normally started in an app. Your question is pretty broad and vague--for example, which OS are you running this on--but this may be what you're looking for. This might also address the question.
Bear in mind when you're asking questions, details are your friend. People can give you a much better, more informed answer when you provide them with details.
EDIT:
In a broader context consider what has to happen from the standpoint of the OS. When the user specifies that they want to run an app, the OS has to load the app from the hard drive and then when the app is loaded into memory, it has to pass control to some point in the memory blocked occupied by the newly loaded app to continue execution. That would be the "Application Entry Point". When an app is constructed with dynamically linked code the OS has to load all that dynamically linked code in order to get the correct app image into memory. Loading up those shared bits of code does not change the fact that the OS must have a point to which to pass control when the app is loaded into memory.