Control order of script executions in test_package - r

Is it possible to control the order in which test_package executes testing scripts? I would like to start by executing some code that creates some objects shared by all individual tests. Therefore, this script needs to be executed first, before the actual test-blabla.R scripts.
I could try something like test-AAA.R or test-000.R, but I am not sure if the dir function used by testthat to list the scripts in a package, returns the same (alphabetical?) order of files on all platforms.

?test_dir says
Test files start with ‘test’ and are executed in alphabetical
order (but they shouldn't have dependencies). Helper files start
with ‘helper’ and loaded before any tests are run.
So, use helper files. i.e. create a file with a name that begins with "helper" and put in it the code that you need to run before running all the tests.

Related

Set default folder in PhpStorm generate test

I'm trying to speed up my workflow for generating tests, and so after assigning shortcut for generate tests, I'd like to avoid selecting the directory every single time.
We have multiple tests directories based on type of the test, but most often I create tests in /tests/unit, which is like 6th of 9 directories that PhpStorm offers. And selecting this over and over really sucks.
Also, I found out that methods are selected based on where your caret is, so that when I'm in the getComposerForDealIncomeType function, it is checked by default. When the cursor is outside of any method, the _construct is pre-selected.
So my goal is following:
set default directory
pre-select all of the functions other than the constructor
Is that possible?

Prevent compiler from moving code from one chunk to another?

I read on this answer the following statement:
"Keep in mind that the compiler can and does move code from one chunk into other chunk output files if it determines that it is only used by that chunk."
Is there any way to switch that off?
I have a 'main' chunk and an 'optional' chunk, and I'm finding the code from the optional chunk is being moved entirely into the main.
My optional code will only be called from the main code, but only if it's determined that we actually want to load the optional stuff (based on a flag that's external to both.)
I want to minimize the size of the main code for cases where the optional stuff isn't needed, but it doesn't seem to be possible with closure as far as I can see.
EDIT:
To split the code I use the -chunk options on the (java) commandline. The 'main' one I point at several folders ('src/Infra/*.js' etc) and use 'auto' for the numFiles for the chunk. The 'optional' I point at three specific files, no wildcard, and specify 3 as numFiles.
To load the 'optional' script the 'main' writes a script tag to the page and has a Promise resolve when it loads. 'optional' is supposed to instantiate the class it defines, and push a reference to that instance to an array in the global namespace, then main reads the ref from the array, and calls an init() method on it, passing in some dependencies.
Is there a better-supported (and equally compact) way of doing it?
EDIT2: in case anyone has a similar issue, I resolved it using the "nameCache" feature of uglifyjs, so the separate components don't necessarily need to be compiled at the same time.
The compiler does not move code "up" the module graph. What's happening is the compiler somehow believes that symbols defined in your optional chunk are directly required.
This most frequently occurs because you are using dependency management and modules. When the compiler sorts dependencies, if any of the "optional" files are directly imported via require for CommonJS, import for ES6 or goog.require for Closure. In this case the compiler adds them to the main module.
To be more specific, I'd actually have to see code.

How run a script refering to an externaly stored script in R?

I am looking for a way to run a script with one part of the script stored in a separate file. Like a "normal" script but with one part of the script referring to an external script.
The script stored in a separate file will be generic to several scripts and will be regularly updated, and that is the reason for keeping this part of the script separate.
I have not found anything about how to solve this. Maybe someone else has a solution to this?
It seems you're looking for
source("[file location]")
Be aware that this will automatically run the entire script in that file location, so be aware of that with regards to which names you give objects in that script and the other script you're working with (e.g. if you open a dataframe in your current script and not in the external script, but you're working with that dataframe in the external script too, the name needs to be the same).
Alternatively, you could write the external script in a way that it is loaded into your workspace as a formula, so that you can refer to that formula in the 'current'script.

R JIT compiler - is there a way to automatically pre-compile all functions in a script? (for use with shiny)

Is there a way to get R to precompile all functions in a script?
The reason it matters is because the script is code for rshiny. I'd like to push forward the byte compiling to occur when the server starts up rather when the user is requesting a page.
I know cmpfun() could be used to compile one function at a time and modify function calls accordingly, but I'd like to do this without maintaining the extra boilerplate code if it's possible.
You should be able to use the JIT from compiler with:
library(compiler)
enableJIT(3)
or set the environment variable R_ENABLE_JIT to non-negative (3 is the highest amount of compilation). I did a quick experiment with my Shiny app and this seemed to produce no benefit at all, so maybe something is not working correctly. This page provides a few more details on R compilation options.

Maintaining same piece of code in multiple files

I have an unusual environment in a project where I have many files that are each independent standalone scripts. All of the code required by the script must be in the one file and I can't reference outside files with includes etc.
There is a common function in all of these files that does authorization that is the last function in each file. If this function changes at all (as it does now and then) it has to changed in all the files and there are plenty of them.
Initially I was thinking of keeping the authorization function in a separate file and running a batch process that produced the final files by combining the auth file with each of the others. However, this is extremely cumbersome when debugging because the auth function needs to be in the main file for this purpose. So I'd always be testing and debugging in the folder with the combined file and then have to copy changes back to the uncombined files.
Can anyone think of a way to solve this problem? i.e. maintain an identical fragment of code in multiple files.
I'm not sure what you mean by "the auth function needs to be in the main file for this purpose", but a typical Unix solution might be to use make(1) and cpp(1) here.
Not sure what environment/editor your using but one thing you can do is to use prebuild events. create a start-tag/end-tag which defines the import region, and then in the prebuild event copy the common code between the tags and then compile...
//$start-tag-common-auth
..... code here .....
//$end-tag-common-auth
In your prebuild event just find those tags, and replace them with the import code and then finish compiling.
VS supports pre-post build events which can call external processes, but do not directly interact with the environment (like batch files or scripts).
Instead of keeping the authentication code in a separate file, designate one of your existing scripts as the primary or master script. Use this one to edit/debug/work on the authentication code. Then add a build/batch process like you are talking about that copies the authentication code from the master script into all of the other scripts.
That way you can still debug and work with the master script at any time, you don't have to worry about one more file, and your build/deploy process keeps everything in sync.
You can use a technique like #Priyank Bolia suggested to make it easy to find/replace the required bit of code.
I ugly way I can think of:
have the original code in all the files, and surround it with markers like:
///To be replaced automatically by the build process to the latest code
String str = "my code copy that can be old";
///Marker end.
This code block can be replaced automatically by the build process, from one common code file.

Resources