各リリース変更のスクリプト検証こんにちは、
多数のスクリプト（> 2000）があり、リリースの変更に実際のコストがかかるクライアントがいます。
実際、彼は新しいリリースを展開する前に、すべてのスクリプトを新しいリリースで検証する必要があります。
経験のある人や、たとえばスクリプトのセットをテストおよび検証できるJSLスクリプトを持っている人はいるでしょうか。
または効果的な他のアプローチ？
ご提案ありがとうございます。
宜しくお願いします、
フローレンス
再：検証デスクリプト注リリース変更リリースこんにちは @flo_kussener 、
これは、10月12日のDiscovery Summit AmericasでのJMP Scripting Unsessionのもう1つの素晴らしいトピックになります。
この話題に興味を持ってくださるお客様も多いと思います。
そのようなセッションを主催するか、あなたの懸念のいくつかを共有するために立ち寄ることを検討してください。
乾杯、
スタン
再：スクリプトの検証は、リリースの変更を注ぐこんにちはフィレンツェ、
一般に、大規模なコーディングやプログラミングを行う場合は、次の2つのことに従う必要があります。
1.1。優れたプログラミング標準/ガイドラインに従う
2.2。ユニットテスト
優れたプログラミング標準は、多くの異なるコーディングスタイルや、非常に一般的な間違いや潜在的な問題を防ぐのに役立ちます。詳細は会社ごとに異なる場合がありますが、優れたプログラミングのための一般的なガイドラインは残っています。
単体テストは、コードが期待される結果を提供するかどうかを確認するのに役立ちます。これは、コードスニペットまたは完全なスクリプトに対して実行できます。通常、すべての成功とエラーが一覧表示されるテストログを取得します。これは、いつでもその単体テストスクリプトをポイントして、結果を当局と共有できるため、検証を高速化するのに役立ちます。2000スクリプトの場合、これは多くの初期作業になる可能性がありますが、そこから進行中は通常、新しいテストを追加する場合など、わずかな変更のみが必要です。
JSL-ユニット-自動化-JSL-テストは、jslスクリプトの単体テストの基本バージョンです。
また、このスレッドは役立つかもしれません： https://community.jmp.com/t5/Discussions/Regression-testing-JSL-scripts-on-new-releases-of-JMP/td-p/9109
私の正直な意見：ほとんどすべてのリリースで、引数、入力/出力、または完全なjsl関数の動作（ソートなど）が変更され、スクリプトが壊れたり、異なるものが提供されたりするため、jslの後方機能テストにもっと注意を払うことを望みます出力。スクリプトを提供し、プログラミング言語を提供していないことは知っていますが...
