Hardened Golo: Have more confidence into your Golo.

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.

Links

• 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

Building HardenedGolo

Dependencies

Hardened Golo

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.

Why and provers

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.

Building Golo

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.

IDE support

Eclipse

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

Netbeans has a recommended community-supported Gradle plugin.

It works with no required manual adjustment on the Golo code base in our tests.

IntelliJ IDEA

Gradle support is native in IntelliJ IDEA.

Note that you may have to adjust the module settings to:

1. remove build from the excluded folders, and
2. add both build/generated/javacc and build/generated/jjtree as source folders, and
3. exclude other folders in build to reduce completion scopes.

Special build profiles

Bootstrap mode

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

Tests console output

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

Verbose tests

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

Testing

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/

License

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

Contributing

We welcome contributions from the community!

Check the CONTRIBUTING.md file for instructions.