The world didn't need another JVM language. So we built yet another one. A simple one.
Hardened Golo is fork of Golo adding some static analysis in order to gain confidence into a Golo program. Since Golo is a dynamic, weakly-typed language for the JVM, Hardened Golo do not support the whole language.
Hardened Golo is developed as part of the research activities of the DynaMid group of the CITI Laboratory at INSA-Lyon.
-
Hardened Golo GitHub: https://github.com/nstouls/HardenedGolo
-
Hardened Golo Wiki: https://github.com/nstouls/HardenedGolo/wiki
-
Golo Website: http://golo-lang.org/
-
Golo GitHub: https://github.com/eclipse/golo-lang
Hardened Golo is built with Gradle. Since the source code contains the Gradle wrapper scripts, the build can bootstrap itself by downloading the qualified Gradle version from the Internet.
Hardened Golo needs Java SE 8 or more to build and run.
Hardened Golo produces some WhyML files, that have to be verified with Why3 tool. This tool could be easily installed on Linux and OSX Systems. You will next need to install some external provers.
Common tasks:
- build:
./gradlew build - test:
./gradlew test - clean:
./gradlew clean - documentation:
./gradlew asciidoctor golodoc javadoc - assemble a working distribution in
build/install:./gradlew installDist - generate a nice JaCoCo tests coverage report:
./gradlew jacocoTestReport
The complete list of tasks is available by running ./gradlew tasks.
You should use the buildship plugin.
Note that you may have to manually adjust the Java source paths to include build/generated/javacc
and build/generated/jjtree.
Netbeans has a recommended community-supported Gradle plugin.
It works with no required manual adjustment on the Golo code base in our tests.
Gradle support is native in IntelliJ IDEA.
Note that you may have to adjust the module settings to:
- remove
buildfrom the excluded folders, and - add both
build/generated/javaccandbuild/generated/jjtreeas source folders, and - exclude other folders in
buildto reduce completion scopes.
Working on the compiler may cause your build to fail because proper compilation and bytecode
generation doesn't work. In such cases the goloc task is likely to fail, and a wide range of unit tests
will break because some Golo source files won't have been compiled.
You can activate the bootstrap mode for that, and focus solely on the Java parts:
./gradlew test -P bootstrap
By default Gradle redirects all tests console outputs, and makes them available from the HTML report
found in build/reports/tests/index.html.
You can instead opt to have all console outputs:
./gradlew test -P consoleTraceTests
It is often desirable to get more outputs from tests, like dumps of intermediate representation trees or generated JVM bytecode.
Such verbosity can be activated using:
./gradlew test -P traceTests
Of course you can combine profiles, like:
./gradlew test -P traceTests -P consoleTraceTests -P bootstrap
Golo provides different types of testing, such as jasmine/mocha like and wrapped approach, the naming conventions, and the decorators (JUnit).
The first in my opinion, even if is not woking with golo, is too long and not very intuitive. By the way, is it possible to implement it in golo by wrapping it within a define method with $ as parameter:
module my.Test
function define = |$| {
$: describe("A Suite", {
$: it("A Test", {
})
$: describe("A cascade Suite", {
})
})
}
An other approach to do testing with golo is to denominate the name of a function with "test_" prefix. This is easy and simple to use and I think that with junit is the best one. Finally let's arrive to junit. JUnit is a unit testing framework for the Java programming language and it is used properly with test driven development which consist in writing test first in order to "drive" the developer towards the implementation of a certain method. So an example of junit testing is:
@Test
function testMultiply = {
assertThat(multiply(10, 0)): isEqualTo(0)
assertThat(multiply(3, 2)): isEqualTo(6)
}
As I said this type of testing is used to do the TDD development, also known as red, green, refactor cycle. Infact in the first phase you write the test but you still don't know the implementation of your program and so it fails. The next step is to write the minimum length of code in order to allow the success of the test and in the third phase the developer will refactor it by improving the structure, and so on.. Moreover one of the pros of using junit is the possibility of using a vaste range of Api's : http://junit.org/junit5/docs/current/api/
Copyright (c) 2012-2016 Institut National des Sciences Appliquées de Lyon (INSA-Lyon) and contributors
All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License v1.0
which accompanies this distribution, and is available at
http://www.eclipse.org/legal/epl-v10.html
We welcome contributions from the community!
Check the CONTRIBUTING.md file for instructions.