Unit testing: Difference between revisions
m
→{{header|Wren}}: Fixed an internal link.
(→{{header|Ruby}}: Add test::unit) |
m (→{{header|Wren}}: Fixed an internal link.) |
||
| (8 intermediate revisions by 4 users not shown) | |||
Line 6:
Clearly state whether this support is internal, or external to the interpreter or compiler used.
=={{header|FreeBASIC}}==
'''fbcunit''' - FreeBASIC Compiler Unit Testing Component<br>
Copyright (C) 2017-2020 Jeffery R. Marshall (coder[at]execulink[dot]com)
Unit testing component for fbc compiler. Provides macros and common code for unit testing fbc compiled sources.
See https://github.com/jayrm/fbcunit.
=={{header|Go}}==
Line 13 ⟶ 21:
For a simple example of the testing process, check out the [[Test_a_function#Go]] task.
=={{Header|Insitux}}==
Alongside assertions and mocking available in pure Insitux (see [https://www.rosettacode.org/wiki/Test_a_function#Insitux Test a function]), the Node.js REPL has the ability to generate a code coverage report of unvisited lines and columns, useful for writing thorough unit tests. Here is a basic demonstration:
<syntaxhighlight lang="insitux" line>
(function subject x y z
(return-unless (num? x) x)
(return-unless (num? y) y)
(if x y z))
(assert (= (subject :a 2 3) :a))
(assert (= (subject 1 :b 3) :b))
(assert (= (subject 1 2 3) 2))
</syntaxhighlight>
{{out}}
Invoked from the terminal with <code>npx ix . -unv</code>.
<pre>
unvisited.txt generated: 1 unvisited (97% coverage)
true
</pre>
<code>unvisited.txt</code>:
<pre>
entry.ix 4 11
</pre>
We're being told here that line 4, column 11 has an expression which was not visited at runtime. Through investigation we see that it's impossible for <code>z</code> to be returned, as <code>x</code> must always be a number - an inherently truthy value.
=={{header|Java}}==
[[User:Sjharper79|Sjharper79]] ([[User talk:Sjharper79|talk]])
===JUnit 5===
Java has a testing library called JUnit. It's current version is 5. Using JUnit, one can develop unit tests for any functionality. I wrote an implementation for the [[Distance and Bearing]] page and use JUnit testing throughout. Below is one of the tests I created to test the ability of the program to properly list the 20 closest airports.
Basically it sets up a List with the 20 airport names expected in the results. Next it executes the method that caculates said result. It compares the result received with the result expected. AssertTrue(correctResults.contains(airport)) tests whether each aiport received in the results is in the list of expected airports. If it is not, the test fails.
<syntaxhighlight lang=java>
package distanceAndBearing;
import static org.junit.jupiter.api.Assertions.assertTrue;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
@DisplayName("Distance and Bearing")
public class DistanceAndBearingTest {
private Airport ap;
@Test
@DisplayName("Should list top 20 airports when searched")
void shouldListTop20AirportsWhenSearched() {
ArrayList<String> correctResults = new ArrayList<>();
correctResults.add("Koksijde Air Base");
correctResults.add("Ostend-Bruges International Airport");
correctResults.add("Kent International Airport");
correctResults.add("Calais-Dunkerque Airport");
correctResults.add("Westkapelle heliport");
correctResults.add("Lympne Airport");
correctResults.add("Ursel Air Base");
correctResults.add("Southend Airport");
correctResults.add("Merville-Calonne Airport");
correctResults.add("Wevelgem Airport");
correctResults.add("Midden-Zeeland Airport");
correctResults.add("Lydd Airport");
correctResults.add("RAF Wattisham");
correctResults.add("Beccles Airport");
correctResults.add("Lille/Marcq-en-Baroeul Airport");
correctResults.add("Lashenden (Headcorn) Airfield");
correctResults.add("Le Touquet-Côte d'Opale Airport");
correctResults.add("Rochester Airport");
correctResults.add("Lille-Lesquin Airport");
correctResults.add("Thurrock Airfield");
List<Airport> results;
DistanceAndBearing dandb = new DistanceAndBearing();
boolean success = dandb.readFile("airports.txt");
results = dandb.findClosestAirports(this.ap.getLat(), this.ap.getLon());
List<String> airports = results.stream().map(ap -> ap.getAirportName()).collect(Collectors.toList());
airports.stream().forEach(airport ->{
assertTrue(correctResults.contains(airport));
});
}
</syntaxhighlight>
=={{header|Jsish}}==
Line 18 ⟶ 123:
Jsish supports an '''internal''' ''-u'' command line option to run unit tests, as part of the base implementation. These tests can include trial inputs and expected outputs in special comment blocks within a source file. Other command line options determine the level of verbosity and logging used when running tests. Being inside comment sections, unit tests do not affect the normal operation of a script (besides the negligible time taken for the interpreter to read in and skip over the comment sections). When in ''-u'' test-mode, source lines starting and ending with semi-colons '';'' are echoed using a special output format that also evaluates the enclosed expression and captures the result.
<
var line = console.input();
var nums = line.match(/^\s*([+-]?[0-9]+)\s+([+-]?[0-9]+)\s*/);
Line 48 ⟶ 153:
-111
=!EXEPECTEND!=
*/</
{{out}}
Line 145 ⟶ 250:
Typical test cases look like:
<
self should:[ 0 ln ] raise:DomainError.
self should:[ 0 log2 ] raise:DomainError.
Line 162 ⟶ 267:
n := sqrt := nil.
self should:[-10 integerSqrt] raise:DomainError.</
When executed headless, a result object is returned from a run, which can be printed or further analyzed.
<br>For example:
<
outcome printCR.
(JSONPrinter encode:outcome) printCR</
{{out}}
<pre>97 run, 97 passed, 0 skipped, 0 failed, 0 errors
Line 193 ⟶ 298:
As a language chiefly intended for embedding, Wren's standard library is quite small and there is no built-in support for unit testing as such.
However, there is an external module called [[
=={{header|zkl}}==
| |||