Just a thought - in the interests of streaming lining / minifying Fantom JS content delivery, perhaps Test code could be left out of the generated Fantom .js files?

I note that in particular the concurrent and graphics pods ship Test code in their .js files, so I assume the other core pods do too.

For instance, I see the following JS classes being delivered to the browser and many more:

• fan.concurrent.ConcurrentMapTest
• fan.concurrent.AtomicTest
• fan.graphics.GeomTest
• fan.graphics.FontTest

Its designed so you can do your builds with the stripTest build config property. Or set the FAN_BUILD_STRIPTEST=true environment variable. See BuildPod

Thanks Brian. Sure, I could re-compile the core pods myself from source...

...I was just thinking that typically one looks to minify JS files, and the Test classes will probably never be used in a prod environment or be tested in a Browser - so perhaps Fantom could look at excluding them from the core pods in future builds?

That way, anyone else looking to use Fantom in a web app doesn't have to re-compile their own distribution.

I understand this may go against the Fantom ethos of bundling test code in pods, but in the case of JS files, I don't see that much benefit in it.

I think we would need to make a decision to always have test code or never have test code in the build zip itself. And if we go never, then that would mean omitting testSys, testCompiler, etc.

I can see both arguments and don't have a strong preference myself. So would be interested in community feedback:

Option A: Include all test cases and test pods in build.zip (todays behavior)

Option B: Omit all test cases and test pods from build zip

I think I've realised this is a actually a tricksy ask!

In general, I'm happy for all code in test/ directories to be left out of distributed pods, but...

...if there's no test code in the pods, then how do you run the tests!?

I guess there'll need to be a build switch to include / exclude test dirs, similar to what there is now, but more accessible from the cmd line.

This on my todo list as well.

...if there's no test code in the pods, then how do you run the tests!?

Yeah generally I want to the test code on the host system -- but not on the target system.

So I've wondered if we shouldn't have a runtime tool that can strip the test classes post-build.

a runtime tool that can strip the test classes post-build.

Hmm, that sounds very prone to error as how would you know post-build which files, classes, and resources were in the test/ directory? And how would you dis-entangle the such compiled source and data from .js files?

Instead I would suggest Fantom enters a more standard means of compilation where file sets dictate which directories are used for various build phases. A cut down version of this idea was already mentioned and largely agreed upon in BuildPod: special configuration for test dirs

But I believe the current feature of the stripTest build config property already does, pretty much, what everyone wants. I was just asking if it could be invoked when building the official Fantom releases.

Trying to solve this at build time is not really practical — remember its not just Fantom core — its any dependencies you have — some of which may not be open source. So you would be at the liberty of whatever the author chose todo. Not to mention it creates extra complexity of "debug" versus "production" pod releases/patches.

So I think you have to solve this at runtime to make it work. I also don’t think you get crazy with static analysis — its just a convention you need to follow — any code under test/ should not be a dependency on anything in your pod.

But you are correct — we probably need a formal way in the build system to identify what is in the test/ directory post-compilation.

Ticket promoted to #2798 and assigned to brian

I'll add a text file into pods which identifies which files can be safely stripped as test code. Then maybe we can have a Build task to strip them?

add a text file into pods which identifies which files can be safely stripped as test code.

Hmm, and then how would you de-tangle and remove test code from the Javascript xxx.js files?

The current stripTest build config property already does a good job removing test source files and resources from the build. All it needs is the ability to specify it in a more dynamic way, like as a cmd line switch.

That way you can keep all the test files during development, and then invoke the switch when it's time to build a release.

Hmm, and then how would you de-tangle and remove test code from the Javascript xxx.js files?

That is going to have to be accomplished using some boundary comments we can search and then strip out the code

All it needs is the ability to specify it in a more dynamic way, like as a cmd line switch.

I thought the fundamental problem here was how to take someone's distributed pods (such as the Fantom distro, or a pod from the internet) and strip out the tests after build

I thought the problem was how to strip out the tests after build

Um, the thread started with me asking if the Fantom distro could be shipped without the tests pre-compiled into the core pods.

Andy then asked if the test classes could be stripped post-build.

Myself, I keep tests in the pod during development so the pod may be tested with fant. When it comes to creating a release, I then run a build with stripTest to create an optimised version.

If you're happy to release Fantom distros with tests pre-stripped, then it's really whichever process works best for you.

I'm not in favor of trying to manage two different pod versions - and trying to make sure everyone on the dependency tree follows the same rules.

Think its easier to say they are always there -- but have an easy way to strip from all pods when you need to. I do think that should be a core tool provided by the build pod though to handle that.

make sure everyone on the dependency tree follows the same rules.

I don't follow - surely it's a personal choice by the pod providers as to whether they ship test code, source code, or other resources in their pods or not?

I personally have never shipped test code in my pods, but the Fantom distro always has.

It's only now that I'm using JS environments more (and size matters!) that I raise the question of the usefulness of test code in the Fantom distro.

I don't follow - surely it's a personal choice by the pod providers as to whether they ship test code, source code, or other resources in their pods or not?

Well it is. But what if they did and you don't want it? Which is exactly your issue :)

So no matter what I think you want a runtime solution to this. And I think I might take it further and really flush out a simplified packaging/deployment API which is really where this logically goes as a next step.

I would most definitely utilize this for Studs - where when I generate the firmware image I copy the flattened pod list over to a staging area - and there I would really want to strip everything - tests, source, docs, etc. Since every byte matters in that case.

Deploy probably is not the right term - but something like:

$ fan build deploy stage/ --strip-docs --strip-test --strip-source

Hmm, then I would also like to take out .js.map and .js files with something like:

--strip-debug --strip-js

But this whole process feels more like a stage in a bespoke deployment pipeline than generic build options - but it sounds like a pipeline process is where you want to take it.

It could be useful and it sounds like you have a real use-case for it, so that's all cool.

But if you want to create a deployment pipeline AND strip the test code out of the Fantom distro, that's cool with me too! :D

Ticket resolved in 1.0.77

I dug into this issue last week.

First off, I've add a new task build::PodRewrite that can be used to strip docs, source, and JavaScript from pods after their have been built.

However, its impossible to fully strip tests after the fact (well not impossible, but very difficult). You can annotate which classes are tests and strip out their fcode. However the way Fantom compiles fcode is that uses single constant pool for the whole pod - this makes Fantom binaries small and fast. But it means all the constants used by the tests can't be easily stripped out. This includes string, uri, type, literals, along with all the type/slot names. So its not practical to strip tests after the pod is built.

So my recommendation is that pods which are officially posted for distribution should be shipped without tests. This would include pods posted on EggBox, StackHub, etc.

And I will strip the test code out from build 1.0.77 and all future builds