I have an Xcode project with a framework target and a separate target for unit tests. Since there is no executable target I can't run the profiling tools without creating a new target, linking against the framework and profiling it that way. However, this means I have to move a lot of code around which unreliable and annoying.
Is there a way I can run the profiling tools (mainly Allocations) on my testing target?
Related
I'm creating a standalone helper utility for use by some of my integration tests. I could write it in a scripting language like Bash or Python, but it would be convenient if it was a Rust binary since that's what the rest of the project is written in and would avoid complicating the project's testing dependencies. However I'm unsure if there's a good way to create a "test-only" binary. I know I could drop something into bin/, but it really shouldn't be used outside of tests so that seems like the wrong location (not to mention it would be compiled even when not needed).
Is there any way to define a binary that's only supposed to be compiled for testing? Sort of like the dev-dependencies config but for a binary rather than a dependency. I tried to see if a tests/bin/ directory would work for example, but it didn't appear to get picked up when running cargo test.
I wrote the crate Rust Test Binary to do this exact thing:
If you have integration tests for things that involve subprocess management, inter-process communication, or platform tools, you might need to write some mock binaries of your own to test against. And if you're already using Cargo to build and test, it would be nice to be able to write those test binaries in Rust, near to the crate you're testing, as cargo projects themselves.
This crate provides a simple interface for invoking Cargo to build test binaries organised in a separate directory under your crate.
Note that you might be able to get away with using a binary in examples, which can be simpler. But my crate is for situations where you need different dependencies, features, or generally want some insulation between your "mock" program compilation and your integration tests.
I was reading the Kotlin documentation and I came across the statement,
By default, your project will use the Gradle build system with Kotlin DSL.
What does it mean?
I've seen Gradle Kotlin option while making a new project in IntelliJ:
Can somebody explain me these, and which Bundle I should be using as a beginner?
A build system combines and simplifies some of the key tasks involved in building and distributing your program. The main things a build system does include:
Downloading any dependencies your application has
Running tests against your application
Compiling your code
Packaging up your application and its dependencies into a form you can share with others
You could run all of these tasks separately yourself, but build systems make it a lot easier and less prone to mistakes. In practice, all but the smallest projects use some kind of build system. Gradle is one such tool, but you can also use Maven, or the tools built into an IDE like IntelliJ.
Which one should I use?
If this is a personal project, the build system and tools built into an IDE like IntelliJ are more than good enough.
If you're working with other people, you might want to consider a standalone build system instead. That's because standalone build systems like Gradle can be used with multiple IDEs, and can also be used on the command line without an IDE at all. Large projects with many contributors will often run a build server that runs the build system in an automated way against all new changes, to make sure the code builds and runs as expected.
IDEs like IntelliJ have very good integration with the common build systems, including Maven and Gradle, so you won't disadvantage yourself by choosing them over the built-in IDE tools.
Maven, Gradle, or Gradle with Kotlin?
There are plenty of other resources you can find comparing Maven with Gradle. The crucial difference, though, is the way you write the build script that allows you to customise the dependencies, tests, and other parameters of your build.
In Maven, your build script is an XML file. It follows a rigid structure, providing inputs and configuration to existing tasks and plugins.
In Gradle, the build script was historically written in Groovy, a loosely-typed language that gives you a lot of flexibility. As well as configuring tasks and plugins, you can easily add your own tasks and functions.
You can also choose to write Gradle build scripts in Kotlin. This offers the same flexibility and customisation as Groovy, but the addition of a type system means the IDE can give you much more help with writing the script correctly.
I am looking for a command line tool that will take googletest executables as an argument and then only runs the fastest tests from that executable. Which those are should be defineable by a given time threshold.
At the first run this tool should run all tests and on further runs it could use the runtimes from the first runs to determine which tests are too slow to be run.
The Visual Studio GoogleTest adapter has such a feature, but I need it as a command line tool, so I can implement a "runFastTests" CMake target that can be used in a fast test-driven development loop.
Thank you for your time.
I have an application that uses the Vuforia SDK (https://www.vuforia.com/) and a feature that does not work in the simulator. I started writing unit tests for this application and I'm not sure why but when I run the tests, it also tries to build the main application and fails because there is no valid architecture for i386.
Is is possible NOT to build the main application? I'm only testing a couple of model classes and a XML parser, no need to build the whole application...
Thanks !
You could put the classes that need testing into a library or framework and make the tests depend on the library. These tests and library will not require the Vuforia SDK.
The executable is a separate target (or even project) depending on the library but is built after the tests.
The unit test target that is created for new projects is an Application Unit Test. It injects your test code into the app by setting BUNDLE_LOADER and TEST_HOST in the build settings. You can create a new unit test target and by default this will be a Logic Unit Test (BUNDLE_LOADER and TEST_HOST are not set). Then add the code you want to test to the new target as well as your app target. Change your scheme to the new target and run your unit tests.
New Target Dialog
Target Membership
Select Scheme
I have a complex project that uses a Ruby::Rake system to generate java (and other) code and do a bunch of other complex things. But I also really like the intellij-idea editor debugger for java etc.
I would want to use my existing scripts I have for various build stages and even dependency checking, code generation before compile, (maybe even the compiling too) generating and deploying data for tests, deploying output to embedded devices, packaging etc etc.
This would be like custom build steps in VisualStudio or "makefile build".
and if one compiles the java with the script, can it's output be directed to play nicely with the IDE for navigating errors and the like.
Ant doesn't do it for me :)
IntelliJ IDEA build system can be integrated with Ant or Maven in the way that it can execute targets automatically before compilation and upon other events. It doesn't work for Rake, but you can wrap rake call into a simple Ant target with exec task.
This way Ant will run rake that will generate java code that will be compiled by IntelliJ IDEA if source root is set to the location where sources are generated.