I am currently trying to refactor an existing gnome-shell extension's codebase. Part of that is introducing unit tests as it seems rather neglectful to not use tests in 2016.
After some tinkering I managed to setup a working node-phantomjs-qunit pipeline that actually gets me somewhere.
However, shell extensions use a custom imports-mechanic as well as
some amendments to build in classes (ex: String.format via GJS) that make it impossible to actually test those files in a isolated environment, that is: not within the shell.
So my question is: Is it really true that it is impossible to write unit tests for shell extensions?
I've done some work with unit tests with gnome shell extensions, take a look at this extension for a complete example:
https://github.com/emerinohdz/power-alt-tab
I've used webpack with babel (optional) and GJS. It is even built using Travis CI.
I've included a dumb polyfill for the GS parts I needed, and provided an alternative to handle modules, using ES6 imports instead of the default GS imports mechanism. No integration tests are possible right now, only unit tests, but at least you have control of most of your codebase.
Related
I'm evaluating ginkgo at the moment - I very much like the BDD style.
However I'm unable at the moment to get the VS Code debugger to work with the framework. The official VS-Code extension provides test-by-test debugging for native go tests using CodeLens. With other languages and frameworks (eg Typescript/Mocha), I've been able to debug individual test files by setting up launch.json appropriately, but have been unable to find suitable examples for go.
Does anybody have any examples of any launch.json setups for debugging ginkgo tests (or go code invoked from any other framework)?
Thanks!
After a bit of playing around I found a way forward which perhaps should have been obvious. In case it isn't I'll leave the question and this answer here:
For a package foo, a foo_suite_test.go file is generated by the gingko bootstrap command. This contains a top-level test called TestFoo which runs the rest of the tests within the package.
This does have a CodeLens run test | debug test section above it which you can use to debug the entire suite.
It's not quite as convenient as the individual CodeLens entries which appear over each native go test, but it's easy enough to isolate specific tests to run using the Gingko F prefix.
I'm trying to figure out if there's a way to see what tests cover the functions in my Go code. I'm working on a code base with other developers so I didn't write all the tests/code myself.
I see some functions that are partially covered, or almost entirely covered, but they have no references anywhere (in its own, or other packages), and the functions aren't called directly in any of the tests.
Is there a way I can find which tests are covering that specific code? When I've tried to find if it's possible, all I get are articles showing how to write/run tests and get coverage percentages/highlighting, but nothing that actually shows if it's possible at all.
For the record, I'm using VS Code on linux and running go test ./... -cover in my terminals, as well as Ctrl+Shift+P -> "Go: Toggle Test Coverage In Current Package" for coverage highlighting within VS Code.
With the fuller picture in view now, via comments, it seems that you have a mess of tests, written by someone(s) less experienced with Go, and your goal is to clean up the tests to follow standard Go conventions.
If I were faced with that task, my strategy would probably be to disable all tests in the repository, by using a build tag that never gets executed, such as:
// +build skip
package foo
Confirm that all tests are disabled, by running go test ./... -cover, and confirm that you have 0% coverage everywhere.
Then, test by test, I would move each test into its proper place, and put it in a new file without the skip build tag.
If it's a big project, I'd probably do one package at a time, or in some other small, logical steps, to avoid a monster pull request. Use your own judgement here.
I'd also strongly resist the urge to do any other cleanups or fixes simultaneously. My goal would be to make each PR a simple copy-paste, so review is trivial, and I'd save a list of other cleanups I discover, to do afterward.
It seems that Logic tests require that I add application files (.m and .h) to the compile target of the test along with the test .m files. I think that this is because Application tests actually load the app side by side with the tests but I am not sure.
Is the bundle loader 'the difference' between Application and Logic tests? I am not talking about why to use them but the distinction between how they work and what they do.
Here you can find a nice description of the tests, with what they do and how they differ. Also, in the next section here, you can read about how to set them up, which reveals the technical differences between them. As you suggested, loading the app bundle seems to make the difference.
Edit: Seems that the links above no longer work, I found a legacy document here: https://developer.apple.com/legacy/library/documentation/DeveloperTools/Conceptual/UnitTesting/UnitTesting.pdf
I'd like to extend ace with a mode for a custom language. As far as I can tell, the general process is:
Download the ace source.
Create a new lib/ace/mode/foo.js for your custom language.
run "make build" (or similar) to rebuild ACE.
Use the newly compiled build/src-min-no-conflict (or whatever) ACE distribution in your website.
But I want to just use an existing ACE distribution from their website, combined with my standalone new mode. I don't want to have to rebuild ACE as part of my build process in order to build my new mode. I got close by doing:
ace.config.setModuleUrl("foo-mode", "./foo.js");
session.setMode("foo-mode");
But I quickly ran into requirejs / dependency problems. For instance I couldn't do require("ace/mode/matching_brace_outdent") inside my mode. I temporarily hacked around that by first calling setMode('ace/mode/c_cpp') (which as a byproduct defines the matching_brace_outdent module). But I ran into even worse problems trying to get a custom WorkerClient to work.
Is my only option to build my mode as part of ACE? Or am I missing something?
Try the pre-built release.
https://github.com/ajaxorg/ace-builds/releases
You might need to edit other files (lists of modes etc.) depending on how you wish to present your new language in the UI:
With regards to require under no-conflict mode in custom modes that aren't workers, if you define your custom mode as a module or a series of modules inside define or ace.define, you should just be able to use the require provided to you in the function wrapper:
ace.define("ace/mode/your_module_name",
["require","exports","module","ace/your_other_dependencies"],
function(require, exports, module) {
// you can use require('...') here
});
I believe you can also use ace.require.
I am less sure about how to "manually build" a custom worker, but following this answer, I think I got it to work by copying code around the core of the relatively slim worker-json.js.
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.