Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
C
clean-test
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
2
Issues
2
List
Boards
Labels
Service Desk
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
clean-and-itasks
clean-test
Commits
25291be5
Verified
Commit
25291be5
authored
Jun 12, 2018
by
Camil Staps
🚀
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Remove makecleantest
parent
bc0869c9
Pipeline
#12114
passed with stage
in 39 seconds
Changes
3
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
3 additions
and
105 deletions
+3
-105
.gitignore
.gitignore
+0
-1
Makefile
Makefile
+3
-17
README.md
README.md
+0
-87
No files found.
.gitignore
View file @
25291be5
Clean System Files/
cleantest
makecleantest
Makefile
View file @
25291be5
BIN
:=
cleantest
makecleantest
BIN
:=
cleantest
CLM
:=
clm
CLMFLAGS
:=
-nr
-nt
-h
100m
-nortsopts
\
-IL
ArgEnv
\
-IL
Platform
\
-I
Cloogle
\
-I
Cloogle/libcloogle
\
-I
Cloogle/CleanPrettyPrint
\
-I
Cloogle/CleanRegex
\
-I
Cloogle/CleanTypes
\
-I
Cloogle/clean-compiler/frontend
\
-I
Cloogle/clean-compiler/backend
\
-I
Cloogle/clean-compiler/main
\
-I
Cloogle/clean-compiler/main/Unix
CLMFLAGS
:=
-nr
-nt
-h
100m
-nortsopts
-IL
Platform
.PHONY
:
all clean
all
:
$(BIN)
$(BIN)
:
Cloogle/clean-compiler
.FORCE
$(BIN)
:
.FORCE
$(CLM)
$(CLMFLAGS)
$@
-o
$@
Cloogle/clean-compiler
:
$(MAKE)
-C
Cloogle clean-compiler
clean
:
$(RM)
-r
**
/Clean
\
System
\
Files
$(BIN)
...
...
README.md
View file @
25291be5
# clean-test [](https://gitlab.science.ru.nl/clean-and-itasks/clean-test/commits/master)
This projects hosts tools that can be used to test Clean programs.
The available tools are:
-
`cleantest`
which can run test programs
-
`makecleantest`
which can generate test programs from dcl modules
## cleantest
This tool can run other test programs and combine the results.
The tool was conceived in
[
clean-platform#17
](
https://gitlab.science.ru.nl/clean-and-itasks/clean-platform/issues/19
)
.
...
...
@@ -36,82 +28,3 @@ cleantest -r testModuleA -r testModuleB
The tool has several command-line options; check
`cleantest --help`
for
up-to-date details.
## makecleantest
This tool can generate test programs using
[
Gast
][]
's
`exposeProperties`
(see
above) from dcl modules. The properties to test are described in
[
CleanDoc
][]
blocks: comments above function types. This works as follows:
-
On the module documentation block, add a
`@property-bootstrap`
field. This
field should contain the 'header' of the generated test program: required
imports and helper definitions. The programmer must not add a module header
(
`definition module ...`
) and does not need to import Gast modules or the
module under test itself.
-
On each function to test, add one or more
`@property`
fields to the docblock.
This property for now always starts with
`A.`
, followed by a number of
parameters and their types. The first line ends with a colon
`:`
. The
implementation of the property follows on the next line(s). For example:
```
clean
/**
* @property member_correct: A.x :: a; xs :: [a]:
* member x (fromList xs) <==> isMember x xs
*/
member
::
!
a
!(
Set
a
)
->
Bool
|
<
a
```
Note that one can use Gast's
`<==>`
here without import, nor does one need to
import the module itself for
`member`
(and
`fromList`
). However,
`isMember`
requires
`import StdList`
in the
`@property-bootstrap`
of the module.
It is possible to use multiple lines for the implementation of the property.
`makecleantest`
will guess the right indentation level.
-
When parameters in
`@property`
fields contain type variables, the programmer
is required to suggest types to instantiate these variables with when
testing
—
otherwise, how would Gast be able to generate test cases?
This can be done with
`@property-test-with`
, either locally on the function
docblock or globally on the module docblock. For example:
```
clean
/**
* @property-test-with a = Int
* @property-test-with a = Real
*/
```
For all relevant tests using the type variable
`a`
, two versions will be
generated: one with
`Int`
and one with
`Real`
. When multiple type variables
are used, all combinations are tested.
-
Sometimes, Gast's generic test generation method is not very useful. This is
for instance the case with types for which automatically generated values are
not 'valid'.
Take
`Set a`
as an example. It is possible to write tests on
`[a]`
instead,
then in every test use
`fromList :: [a] -> Set a`
to get the set. However,
this is not very modular, and also clutters up the properties.
What you can do instead is writing tests as you would normally do,
quantifying over
`Set a`
in the property signature, and then add a
`@property-test-generator`
to the module. This field tells the test generator
how to generate values of a certain type. An example is:
```
clean
/**
* @property-test-generator [a] -> Set a | < a
* gen xs = fromList xs
*/
```
Currently, only generators with arity 1 are supported (but this can be worked
around using a tuple or an auxiliary data type in the
`@property-bootstrap`
).
When the generator has class constraints, you are expected to resolve them
yourself by providing the required instances, depending on the type variable
instantiations.
[
Gast
]:
https://gitlab.science.ru.nl/clean-and-itasks/gast
[
CleanDoc
]:
https://github.com/clean-cloogle/Cloogle#clean-documentation
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment