Acceptance Tests

We’re excited to introduce a powerful new feature in the Plain language: Acceptance Tests.

Acceptance tests can be used to further refine the functional requirement and especially to incorporate constraints on the implementation.

Acceptance tests are specified with a keyword ***Acceptance Tests:*** as a subsection within ***Functional Requirements:*** section. Each acceptance test must be an item in a list.

Here's an example of a "Hello, World" application with one acceptance test.

***Functional Requirements:***

- Display "hello, world"

  ***Acceptance Tests:***
    
  - The App shouldn't show logging output in the console output (neither in stdout nor stderr).

Acceptance tests extend conformance tests. The acceptance tests are implemented according to the Test Requirements: specification (see next section).

If you have any questions or feedback, we’d love to hear from you.

Improved Developer Experience

In this release, we've focused on enhancing the developer experience. Console logs have been cleaned up, and the phases of the code generation process are now more clearly defined. Additionally, verbose logs from unit and conformance tests have been redirected to external files, resulting in a much cleaner overall log output. Developers can still access these files to examine detailed test results as needed.

We’ve also strengthened the code generation process by introducing a more robust workflow for handling failed unit tests, particularly after feature requirements have been successfully implemented.

Plain Client Upgrade

Dear Plain Programmer,

As our team continues to grow, we're making exciting improvements to our code generation service. To support these enhancements, we've introduced a few updates to the client.

All existing Plain source files should remain fully compatible with the new version, but we kindly recommend pulling the latest updates from our repository: https://github.com/Codeplain-ai/plain2code_client.

Best regards,
The Codeplain Team

Better handling of syntax errors in Plain source

In this release we provide better error handling for syntax errors in Plain source. Now it should be much easier to understand what is wrong with the Plain source if the rendering fails.

Besides better handling of syntax errors and fixing a few bugs, this release also:

• updates unittests and conformance tests scripts
• adds Golang console app template to the standard template library
• adds prohibited_chars liquid filter

Standard template library implementation

Introducing support for standard template library. Standard templates are a predefined Plain source files that can be used as a starting point for building applications. Initially standard templates are available for the following languages/application types:

• Python Console Application (python-console-app-template.plain)
• Go Lang Console Application (golang-console-app-template.plain)
• TypeScript React Web Application (typescript-react-app-template.plain)

Standard templates reside in the standard_template_library folder. See also examples for more information how standard templates can be used.

In addition to standard templates and bug fixes, the new version also introduces:

• renaming end-to-end tests to conformance tests to align ourselves with the nomenclature used by Tessl.io,
• '--full-plain' command line flag that returns full plain text source with all templates applied.

Sections support

Added support for sections in Plain source files. This means that Plain source can be organized in sections and subsection using markdown headers. This should enable support for bigger and more complex applications written in Plain in the future.

Liquid templates support

Added support for Liquid templates in Plain. Liquid is an open-source template language created by Shopify (https://shopify.github.io/liquid/).