For a normal Flash/Flex application I would include my Unit Tests in my application project (perhaps in a tests source folder alongside my main src folder). I'd then have two application entry points: the app, and it's tests.
How are people doing this for their Flex Library Projects? You know, the kind that produces a SWC file. As far as I can tell, you can't set an executable entry-point for these projects (to run the tests).
Normally, Flash Builder only allows you to use the debugger from a Flex/AIR application, not a library project. So best thing to do here is load the library into a Flex application and write+debug tests there.
Here are step-by-step instructions to be able to test your library project, with debugging/stepping enabled:
Create a Flex Library project that you want to test + debug
Create a normal, empty Flex Application. We will write the tests in this dummy Flex Application so we can utilise the debugging features.
Set the library's build-path to the 'libs' folder of the Flex Application so it builds most recent code into a swc loaded by the Flex Application.
Optionally, set the
Flex Application to 'reference'
the library project in Project
Properties->Project References, this
ensures the library code is built first.
Write your tests in the Flex
Application
Debug and run your tests: you
should be able to step through your library
source code! Nice.
Optionally, once you're satisfied your tests are all good
copy your tests back into the
library project to keep all the library's associated code together in one project. Make sure you're not including the test classes in the actual library swc.
This is how I do it anyway.
If we assume that you need an mx:Application entry point to run the unit tests, then it would seem to make sense to generate a separate application project solely to run the tests.
Would you really want to include the unit tests in the compiled SWC anyway? (For an application this wouldn't be a problem since they're, presumably, not referenced, but for a SWC library I think they'd be compiled in if they're in the folder hierarchy somewhere)
In Flash Builder Beta 1 onwards itself, you can write and execute Flexunit tests from a library project.
You can use the IDE integration feauture of FlexUnit, and select the project, folder , class or method from the context menu and use "Execute Flex Unit Tests". This will create the application file of the required syntax, run the application and show the results in the FB. You can even select from the result and run the tests are requried.
There isn't currently a way to test a library project. You must have an application as the entry point to the tests. This would be a great feature request for Flash Builder 4.
Related
I have my tests defined in .NetStandard project (assembly) (as I need to test them through very different platforms).
We can't run those directly as it requires the project to target something like .NetFramework or .Net Core.
So, I've created .Net Core project and referencing my .NetStandard project.
However, when running dotnet test ...csproj I obviously receive
No test is available in .... Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
... as there is obviously no magic and testing adapter can't read my mind and go to any referenced assembly automatically.
That seems that the tests discoverer just doesn't look at the attached assemblies with tests.
However, there must be some way of mentioning that to it, right?
The documentation is quite modest about that, so I don't even know if this approach in general possible.
However, when testing Xamarin.iOS/Android with TestRunners, they always have the option to add my assembly to test, like this: runner.Add(typeof(MyTestClass).Assembly).
Just to be clear, that this question point is not actually about targeting different platforms issue, but finding the way of running tests from .Net Core project (the way it already works for Xamarin):
One of the solutions for this is creating an inherited class in .NET Core project from the class(es) of .NETStandard project:
[TestFixture]
public class TestsClassInNetCoreProject : TestsClassInNetStandardProject
{
// ...
}
(it would work both ways: either from command line or from VS "Run Tests" menu) but this is of course not the best way of handling this.
Just to summarize:
The tests should be placed in separate project/assembly as for Xamarin test projects they don't actually run in common way tests run (they run via a test runner inside of actually an iOS/Android app).
This way it's handy to have the tests in .NETStandard assembly, which can be attached anywhere else.
Again, this already works for Xamarin (platform-specific project attaching my .NETStandard library with tests) via a test runner (NUnit one), but it doesn't for .NET Core project.
I don't need to run the tests on the .NET Standard assembly itself (what is even not possible), I need they to be referenced from testable .NET Core project.
Is there any way I can be lucky with that?
I'm building a Flex/AIR application that connects to a remote server, the URL of which changes depending on the environment (development/production, and possibly others). For now, this URL parameter is hardcoded in my root application MXML file but it means I have to change it everytime I build my app for a different environment.
Is there a way to externalize such a parameter so that when Flash Builder automatically builds my app (in development mode), it uses the development URL (http://localhost...) and when Flash Builder exports a release build, it uses the production URL (http://www.mycompany.com/myapp)?
Flex compiler supports something called Conditional compilation, you an read about it here: link. The problem is that it still doesn't give you an way to check if you're exporting a release build or building for debug. Probably the simplest way to achieve that is to use ANT for compilation of the release build and use the conditional compilation from there.
I'm preparing to reorganize & refactory a Flash Builder application. The goals of the reorg are 1.) keep compile times for the part of the project I'm working on as fast as possible, 2.) keep the unrelated parts separate for code reuse. Goal #1 trumps goal #2 if there's a trade-off.
Currently, the app has assets in one project, core functionality AS3 in another project, and the MXML in a third project that links to the other two.
Would moving resources/code into swc libraries help compile time? What about compiling assets into an swf and embedding that into the main application? Any other techniques?
We had the same problem, application compile time was more than 1 minute.
Here is our solution:
There is a Core Library that contains class Core with static properties like: Core.resourceManager:IResourceManager, Core.stringManager:IStringManager, etc.
Main application project includes Core Library and provides implementation for all Core.someProp. This can be done via some hidden method like Core.setImpelentation().
There are unlimited number of Modules that use Core Library to contribute their display / logic to the application. Important:
Each Module is a separate Flash Builder project
Module link Core Library as external (it's included in Main App)
Module has XML-file that describes it, example it's name and icon in application control bar. It allows not to load all modules at start.
User should be able to choose which modules he would like to use. This will also help you in development.
You can optionally create Lib Library and include in it all classes that are common between modules and can be implemented using Core Library.
The result is incredible - you application becomes low-coupled, open/compile time decreases, APIs become more clear. Profit!
Modules are definitely the way to go here, as Maxim has described. Further to his advice, which is all solid, here's some other tips:
Extract styles out to a separate project, and compile the .css to a SWF. Load the SWF at runtime.
Structure your packages by business function first, MVC role second,
Eg: Rather than com.myapp.model.userconfig.UserOptions, use com.myapp.userconfig.model.UserOptions. Enforce that packages can only reference their siblings, or com.myapp.core.*.
This way, each package is a self contained module, which only references itself, or the core library.
Consider the Hellfire Compiler, which can farm your compilation over several CPU's in parallel
If not already, consider moving to the Flex 4 SDK, which has several compiler performance improvements, especially around compiling multiple SWC's.
I'm using Flexbuilder as an IDE, and I'm working on automating the process of building my application.
In the process of setting up the ant build file, I noticed that there's no way to call the project using the list of dependancies that Flex builder stores - each library or library project has to be added to the flex compiler commands manually. This creates an enormous burden on the developers to update the build scripts, and makes the build process very uncomfortably fragile.
Is there an option or third party project that addresses this? Failing that, is it possible to build using Flex builder's process via command line?
This answer might be of use.
automating component libraries
My team builds reusable libraries for other (internal) software development teams. We use FlexBuilder 3 as our development environment. Our SCM standards state that these projects must include test harnesses and a unit test runner, and (of course) we want to be able to use the debugger. For that reason, all the projects are Applications.
Our build scripts (used primarily by the CI system and for release deployment) build our actual libraries which works great. This approach is used so that FlexBuilder is not required to actually build our production artifacts (on the command line).
The problem is this - in order to have add a FlexBuilder Project to the Library Path for an Application it must be a Library Project. I have tried adding a nature to the project that we want included, but haven't gotten it to work yet. You would want to do that if you wanted to debug source files in another project.
A simple (yet annoying) work around is to include the source folder of the "library project" as a source folder in the "application project." It's annoying because it takes multiple steps to swap between a swc of the "library project" and the source folder of the project itself.
I would also suggest breaking this up into 2 projects. Have 1 library project and 1 application for the tests and the testrunner.
On a sidenote: FlexBuilder 4 will have support for running FlexUnit tests in the IDE, for both Flex applications and Flex library projects. So you won't have to maintain an application just for the sake of running the tests.
Assuming it is possible, I'd suggest adjusting your SCM standards to allow test harnesses and unit test runners to exist in other projects. Simply mandate that any library project must include a companion test project.
I don't know that this is going to make it any easier, but I would actually make the library and the testing harness seperate projects. This would allow you to source control each and would solve your problem with flexbuilder. Its not going to make it easier to work with, but it will be cleaner and the easiest to update.
I didn't totally understand the description of your situation, but if it's helpful, I'll describe how we have organized our Flex projects. The majority of our application code is contained within a SWC ("library") project. We then create two SWF ("application") projects - a "shell" application which represents the final output SWF, and a test harness FlexUnit 2 application. Both of these SWF projects reference the SWC project using a source path. Using this approach has made it trivial to enable unit testing for the application codebase in the SWC.