Unit testing: Difference between revisions
m
→{{header|Wren}}: Fixed an internal link.
m (→{{header|Wren}}: Fixed an internal link.) |
|||
| (16 intermediate revisions by 9 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 57 ⟶ 162:
123 -234
-111</pre>
=={{header|jq}}==
jq was developed with unit testing, and the jq source includes a suite of unit tests that utilize the --run-tests option of the jq command. This option expects unit tests to be presented in the form of "paragraphs" that may be specified in one or more files, which by convention have ".test" as the filename suffix.
Here is an example of such a .test file with explanatory comments, followed by a transcript showing how it is used and the output that is produced.
'''Unit Test File'''
<pre>
# unit-tests.test
# Basic tests are groups of three lines: program, input, expected output
# Blank lines and lines starting with # are ignored
# For example:
true
null
true
# Failure tests begin with a %%FAIL line, followed by the program and the expected error message.
# %%FAIL tests have no input line.
%%FAIL
{(0):1}
jq: error: Cannot use number (0) as object key at <top-level>, line 1:
# Testing the testing apparatus:
length
"This should generate an error"
0
</pre>
'''Transcript'''
<pre>
$ jq --run-tests unit-tests.test
Testing 'true' at line number 5
Testing '{(0):1}' at line number 12
Testing 'length' at line number 16
*** Expected 0, but got 29 for test at line number 18: length
2 of 3 tests passed (0 malformed)
</pre>
=={{header|Julia}}==
Julia was developed with unit testing, and testing with macros such as @test are part of the language specification. See
https://docs.julialang.org/en/v1/stdlib/Test/index.html.
=={{header|Nim}}==
Nim provides two mechanisms for unit testing.
The first one is the module <code>unittest</code> which allows to define tests and test suites. The documentation for this the module can be found here: https://nim-lang.org/docs/unittest.html
The second one is a more advanced tool named <code>testament</code> which is used for the development of Nim itself. It offers process isolation for the tests, can generate statistics about test cases, supports multiple targets (C, C++, ObjectiveC, JavaScript, etc), can do simulated Dry-Runs, has logging, can generate HTML reports, can skip tests from a file, and more.
Its documentation can be found here: https://nim-lang.github.io/Nim/testament.html
=={{header|Phix}}==
Line 85 ⟶ 236:
Also, most REXXes authors/creators/programmers/development teams have accumulated a suite of test programs that exercise a major part of the aspects and nuances of the REXX language and can usually find defects in the interpreter. Another method is to run/execute [https://en.wikipedia.org/wiki/A/B_testing '''A/B'''] type of testing, that is, run/execute REXX programs with two (or more) different REXX interpreters and compare results. Since REXX does arithmetic using decimal numbers (including "floating point"), errors (even minute ones) are easy to identify. Indeed, some (if not many) of the programs entered here on Rosetta Code have provided some REXX developers a very good starting base for a comprehensive test suite.
=={{header|Ruby}}==
[https://ruby-doc.org/stdlib-3.0.2/libdoc/minitest/rdoc/minitest-5_14_2/README_rdoc.html Minitest] and [https://ruby-doc.org/stdlib-3.0.2/libdoc/test-unit/rdoc/Test/Unit.html test::Unit] are the testing libraries which ship with Ruby.
=={{header|Scala}}==
The main Scala testing frameworks ( [http://www.scalacheck.org ScalaCheck], [http://www.scalatest.org ScalaTest], and [http://www.specs2.org specs2]) provide an implementation of the common test interface and only need to be added to the classpath to work with [https://www.scala-sbt.org/ sbt].
=={{header|Smalltalk}}==
All Smalltalk dialects have a testing framework included, which is typically based on the original [https://en.wikipedia.org/wiki/SUnit SUnit test framework].
Tests are subclasses of TestCase, and define test methods. Execution and visual presentation can be within the class browser or a UnitTest runner (which are part of the system), but tests can also be executed "headless" (i.e. without UI).
Obviously, this is defined in the class library, because in Smalltalk everything comes from the class library
Typical test cases look like:
<
self should:[ 0 ln ] raise:DomainError.
self should:[ 0 log2 ] raise:DomainError.
Line 112 ⟶ 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 139 ⟶ 294:
...
hundreds of more lines</pre>
=={{header|Wren}}==
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 [[:Category:Wren-test|Wren-test]] which can be used for this purpose and whose documentation should be consulted for the features it contains.
=={{header|zkl}}==
| |||