chutney-testing / chutney-testing.github.io-legacy

Chutney testing website

Developer setup

Follow https://www.mkdocs.org/getting-started/ & https://squidfunk.github.io/mkdocs-material/getting-started/

Run :

• Via Python
  • pip install mkdocs mkdocs-material mkdocs-git-revision-date-localized-plugin mkdocs-redirects
  • mkdocs serve in the project root folder
  • Visit http://localhost:8000/
• Via Docker (in case you are not a big python fan)
  • build an image from de provided Dockerfile docker build -t chutney/doc .
  • in the project root folder run docker run --rm -p 8000:8000 -v ${PWD}:/docs chutney/doc
  • Visit http://localhost:8000/

chutney-testing.github.io-legacy's Issues

Feedback

Overview

• I find there is too much text. It should be better to have less text, more links to others pages. Just keep text until the getting started link. The others sections in an other pages. ✅
• I would like to add an image like the one which compare Chutney to others tests tools in section "Why another test tool" ✅

Getting started

• graddle => gradle
• minimal setup section : i will add two links to two example projects for maven (https://github.com/chutney-testing/chutney-kotlin-dsl/blob/master/example/pom.xml) and kotlin (https://github.com/chutney-testing/chutney-kotlin-dsl/blob/master/example/build.gradle.kts) ✅
• kotlin section => Specific to kotlin, not to Chutney => make a note to gain space ✅
• The page is too long, i will split the page like that : ✅
  • Introduction + Minimal setup
  • Write your first scenario
  • Run your scenario

Write your first scenario

• "Here we use the Chutney Kotlin DSL to declare a target." => redundant, remove ✅
• "Here we use the Chutney Kotlin DSL to declare an environment." => redundant, remove ✅
• "As you can see," => too much , to remove As you can see, ✅
• i dont like the name of the variable "www". I prefer to have something like myTestingEnvironment
• "Here we use the Chutney Kotlin DSL to declare a Scenario."' => redundant, remove ✅
• "As you can see" => remove ✅

Run your scenario

• I prefer to begin with the junit way than the launcher wau ✅

• "As you can see, this is a simple JUnit test."=> remove ✅

• "Configure your build tool" => collapsable to take less space ✅

• add a link to our example :

  • https://github.com/chutney-testing/chutney-kotlin-dsl/blob/master/example/src/test/kotlin/com/chutneytesting/ChutneyEngineTest.kt
  • https://github.com/chutney-testing/chutney-kotlin-dsl/blob/master/example/src/test/kotlin/com/chutneytesting/DefaultWrappingTest.kt

• "The JUnit5 engine does not take environment definition from Kotlin but instead from JSON files." => false ? To be verified 💥

Synchronize function can create remote scenario (update this doc Server installation -)

Update : https://www.chutney-testing.com/installation/ci_cd/scenario_sync/#create-or-update-your-kotlin-scenario

Add link to the code in each action

Above each each action title

add a info box with message :

See [link_to_the_package_of_the_actions] for implementation details

Kafka action documentation

Make real example for filter
Details filter header/body behavior

Should be Duration.ofHours(6)

https://github.com/chutney-testing/chutney-testing.github.io/blame/31145366b09035b45c9b3059f49343e0b59ad187/docs/documentation/functions/datetime.md#L153

Review AMQP action documentation (finally tasks,...)

Pay attention to parallel task run
Remove start/stop server
Make real example for filter
Details filter header/body behavior

Selenium action documentation

Micrometer action documentation

Add link to micrometer documentation
Explain how to get metrics registry

Packaging - Task -> Action Check conf nbLoggedRows

🙋 | Collect Questions

Ask your question or suggest your idea !

This is for us to keep track of recurrent questions we could document properly

• How to access properties on a target during execution ?
  • target.property('myProperty').get()".spEL() or ${#target.property('myProperty').get()}

---

note: this could be a duplicate use of discussions

Add documentation on plugin intellij

Explain how to create custom actions

🙋 | Improve documentation consistency

Ask your question or suggest your idea !

As we talked about it,
there is a lot of overlap or unclear use cases between Getting Started, Installation and Integration.

First idea would be to explicit use cases such as :

• Quick start with local development
• Installing a Chutney server in production
• Daily use syncing local development and shared server

Example

Left menu

• Installation

  • Local Development

  • On-premise

    • Introduction
    • Minimal configuration
      • Maven confguration
      • Logback
      • Minimal Application.yml
    • Further details
      • Database
      • Logs
      • Server (TLS/SSL)
      • etc.

  • advance topic

    • liquibase
    • metrics produite
    • authentification ldap
    • compression
    • session management
    • actuator
    • specifics value

  • CI/CD integration

    • synchronize

:sparkles: Enrich tasks documentation

Take inspiration from the documentation already written for the action HTTP
Feel free to write all or part of the actions in each sections.
NB: task == action but we dont have merged the PR yet

• AMQP (9 actions) Need to be review in depth (finally action,...)
• Assertions (7 actions)
• Groovy (1 action)
• Jms (5 actions)
• Kafka (4 actions)
• Micrometer (6 actions)
• Mongo (6 actions)
• Radius (2 actions)
• Selenium (16 actions)
• Sql (1 action)
• Ssh (9 actions)

Others tasks

• Add link to the code in each action

🙋 | Add scenario example to give more insight to functions

Ask your question or suggest your idea !

Overall, we still need to add missing info or examples on function parameters.
Maybe we could also provide more "context" about how and why one would use a given function, to improve further understanding and to help users to have "testing" ideas and capabilities

Describe your use case

No response

Verify prefix properties documentation

On SQL and JMS actions. (May be others ?)

SQL with new sugar syntax

Groovy action documentation

Look if there is no sanboxing/exlude class from groovy classpath