Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🧠 Logic: ♻️ Refactor prolog predicates testing methodology #498

Closed
ccamel opened this issue Jan 7, 2024 · 1 comment
Closed

🧠 Logic: ♻️ Refactor prolog predicates testing methodology #498

ccamel opened this issue Jan 7, 2024 · 1 comment

Comments

@ccamel
Copy link
Member

ccamel commented Jan 7, 2024

Overview

Currently, our testing approach for Prolog predicates relies on the smartystreets/goconvey library. This method uses a data-driven strategy where test data encapsulates use cases, including the program to execute, the query, the desired result, and any errors. Though effective and functional, this approach is becoming increasingly cumbersome and code-intensive when writting tests for new predicates.

Proposal for Refactoring

The proposed change involves shifting towards pure Prolog testing. In this new framework, smartystreets/goconvey would be primarily used for setting up test scenarios. This setup includes initializing the Prolog interpreter, declaring the predicates under test, and establishing the relevant context. However, the core of the testing would be conducted entirely in Prolog.

The benefits is a reduced complexity: by leveraging Prolog for assertions, we can simplify the testing process, making it more intuitive and especially maintainable.

Approach

To facilitate this transition, we would need to integrate a basic test (test/1, test/2) predicate, implemented in Go for expressing test cases in Prolog. This predicate would be pivotal in writing concise and clear test cases within the Prolog environment.

Example:

The following use case data for testing the bech32_address/2 predicate:

{
	query: `bech32_address(-(Hrp, Address), 'okp415wn30a9z4uc692s0kkx5fp5d4qfr3ac7sj9dqn').`,
	wantResult: []types.TermResults{{
		"Hrp":     "okp4",
		"Address": "[163,167,23,244,162,175,49,162,170,15,181,141,68,134,141,168,18,56,247,30]",
	}},
	wantSuccess: true,
},

could be replaced with the following prolog unit test:

test(bech32_address_ok,
	[true(Hrp == 'okp4'), 
	 true(Address == [163,167,23,244,162,175,49,162,170,15,181,141,68,134,141,168,18,56,247,30])]) :-
    bech32_address(Hrp-Address, 'okp415wn30a9z4uc692s0kkx5fp5d4qfr3ac7sj9dqn').
@ccamel
Copy link
Member Author

ccamel commented May 15, 2024

Deprecated. A different strategy has been implemented by #579, opting for a test methodology approach based on Gherkin - a textual, behavior-oriented approach that is human oriented, simple to implement, highly extensible.

@ccamel ccamel closed this as completed May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

No branches or pull requests

1 participant