test(analyser): add debug_test

Author: juleswritescode

Cargo.lock

@@ -94,7 +94,7 @@ pub trait Rule: RuleMeta + Sized {
 }
 
 /// Diagnostic object returned by a single analysis rule
-#[derive(Debug, Diagnostic)]
+#[derive(Debug, Diagnostic, PartialEq)]
 pub struct RuleDiagnostic {
     #[category]
     pub(crate) category: &'static Category,
@@ -109,7 +109,7 @@ pub struct RuleDiagnostic {
     pub(crate) rule_advice: RuleAdvice,
 }
 
-#[derive(Debug, Default)]
+#[derive(Debug, Default, PartialEq)]
 /// It contains possible advices to show when printing a diagnostic that belong to the rule
 pub struct RuleAdvice {
     pub(crate) details: Vec<Detail>,
@@ -118,7 +118,7 @@ pub struct RuleAdvice {
     pub(crate) code_suggestion_list: Vec<CodeSuggestionAdvice<MarkupBuf>>,
 }
 
-#[derive(Debug, Default)]
+#[derive(Debug, Default, PartialEq)]
 pub struct SuggestionList {
     pub(crate) message: MarkupBuf,
     pub(crate) list: Vec<MarkupBuf>,
@@ -160,7 +160,7 @@ impl Advices for RuleAdvice {
     }
 }
 
-#[derive(Debug)]
+#[derive(Debug, PartialEq)]
 pub struct Detail {
     pub log_category: LogCategory,
     pub message: MarkupBuf,

crates/pg_analyse/src/rule.rs

@@ -35,6 +35,7 @@ We follow a naming convention according to what the rule does:
 A rule should be informative to the user, and give as much explanation as possible.
 
 When writing a rule, you must adhere to the following **pillars**:
+
 1. Explain to the user the error. Generally, this is the message of the diagnostic.
 1. Explain to the user **why** the error is triggered. Generally, this is implemented with an additional node.
 1. Tell the user what they should do. Generally, this is implemented using a code action. If a code action is not applicable a note should tell the user what they should do to fix the error.
@@ -53,6 +54,7 @@ Let's say we want to create a new **lint** rule called `useMyRuleName`, follow t
    ```shell
    just new-lintrule safety useMyRuleName
    ```
+
    The script will generate a bunch of files inside the `pg_analyser` crate.
    Among the other files, you'll find a file called `use_my_new_rule_name.rs` inside the `pg_analyser/lib/src/lint/safety` folder. You'll implement your rule in this file.
 
@@ -127,6 +129,7 @@ The compiler should warn you that `MyRuleOptions` does not implement some requir
 We currently require implementing _serde_'s traits `Deserialize`/`Serialize`.
 
 Also, we use other `serde` macros to adjust the JSON configuration:
+
 - `rename_all = "snake_case"`: it renames all fields in camel-case, so they are in line with the naming style of the `pglsp.toml`.
 - `deny_unknown_fields`: it raises an error if the configuration contains extraneous fields.
 - `default`: it uses the `Default` value when the field is missing from `pglsp.toml`. This macro makes the field optional.
@@ -159,7 +162,6 @@ pub enum Behavior {
 
 Below, there are many tips and guidelines on how to create a lint rule using our infrastructure.
 
-
 #### `declare_lint_rule`
 
 This macro is used to declare an analyzer rule type, and implement the [RuleMeta] trait for it.
@@ -235,6 +237,7 @@ impl Rule for BanDropColumn {
 ### Document the rule
 
 The documentation needs to adhere to the following rules:
+
 - The **first** paragraph of the documentation is used as brief description of the rule, and it **must** be written in one single line. Breaking the paragraph in multiple lines will break the table content of the rules page.
 - The next paragraphs can be used to further document the rule with as many details as you see fit.
 - The documentation must have a `## Examples` header, followed by two headers: `### Invalid` and `### Valid`. `### Invalid` must go first because we need to show when the rule is triggered.
@@ -246,7 +249,7 @@ The documentation needs to adhere to the following rules:
 
 Here's an example of how the documentation could look like:
 
-```rust
+````rust
 declare_lint_rule! {
     /// Dropping a column may break existing clients.
     ///
@@ -269,12 +272,26 @@ declare_lint_rule! {
         sources: &[RuleSource::Squawk("ban-drop-column")],
     }
 }
-```
+````
 
 This will cause the documentation generator to ensure the rule does emit
 exactly one diagnostic for this code, and to include a snapshot for the
 diagnostic in the resulting documentation page.
 
+### Testing the Rule
+
+#### Quick Test
+
+To quickly test your rule, head to the `pg_analyser/src/lib.rs` file and modify the `debug_test` function.
+
+You should:
+
+- remove the `#[ignore]` macro if present
+- change the content of the `SQL` static `&str` to whatever you need
+- pass your group and rule to the `RuleFilter::Rule(..)`
+
+If you run the test, you'll see any diagnostics your rule created in your console.
+
 ### Code generation
 
 For simplicity, use `just` to run all the commands with:
@@ -294,15 +311,14 @@ Stage and commit your changes:
 > git commit -m 'feat(pg_analyser): myRuleName'
 ```
 
-
 ### Deprecate a rule
 
 There are occasions when a rule must be deprecated, to avoid breaking changes. The reason
 of deprecation can be multiple.
 
 In order to do, the macro allows adding additional field to add the reason for deprecation
 
-```rust
+````rust
 use pg_analyse::declare_lint_rule;
 
 declare_lint_rule! {
@@ -328,5 +344,4 @@ declare_lint_rule! {
         sources: &[RuleSource::Squawk("ban-drop-column")],
     }
 }
-```
-
+````

crates/pg_analyser/CONTRIBUTING.md

@@ -16,3 +16,8 @@ pg_analyse   = { workspace = true }
 pg_console   = { workspace = true }
 pg_query_ext = { workspace = true }
 serde        = { workspace = true }
+
+[dev-dependencies]
+termcolor =   { workspace = true }
+pg_query = { workspace = true}
+pg_diagnostics = { workspace = true}

crates/pg_analyser/Cargo.toml

@@ -65,3 +65,61 @@ impl<'a> Analyser<'a> {
             .collect::<Vec<_>>()
     }
 }
+
+#[cfg(test)]
+mod tests {
+    use core::slice;
+
+    use pg_analyse::{AnalyserOptions, AnalysisFilter, RuleFilter};
+    use pg_console::{
+        fmt::{Formatter, Termcolor},
+        markup, Markup,
+    };
+    use pg_diagnostics::PrintDiagnostic;
+    use termcolor::NoColor;
+
+    use crate::Analyser;
+
+    #[ignore]
+    #[test]
+    fn debug_test() {
+        fn markup_to_string(markup: Markup) -> String {
+            let mut buffer = Vec::new();
+            let mut write = Termcolor(NoColor::new(&mut buffer));
+            let mut fmt = Formatter::new(&mut write);
+            fmt.write_markup(markup).unwrap();
+
+            String::from_utf8(buffer).unwrap()
+        }
+
+        const SQL: &str = r#"alter table test drop column id;"#;
+        let rule_filter = RuleFilter::Rule("safety", "banDropColumn");
+
+        let filter = AnalysisFilter {
+            enabled_rules: Some(slice::from_ref(&rule_filter)),
+            ..Default::default()
+        };
+
+        let ast = pg_query_ext::parse(SQL).expect("failed to parse SQL");
+
+        let options = AnalyserOptions::default();
+
+        let analyser = Analyser::new(crate::AnalyserConfig {
+            options: &options,
+            filter,
+        });
+
+        let results = analyser.run(crate::AnalyserContext { root: &ast });
+
+        println!("*******************");
+        for result in &results {
+            let text = markup_to_string(markup! {
+                {PrintDiagnostic::simple(result)}
+            });
+            eprintln!("{}", text);
+        }
+        println!("*******************");
+
+        // assert_eq!(results, vec![]);
+    }
+}

crates/pg_analyser/src/lib.rs

@@ -195,7 +195,7 @@ where
     }
 }
 
-#[derive(Debug)]
+#[derive(Debug, PartialEq)]
 /// Utility type implementing [Advices] that emits a
 /// code suggestion with the provided text
 pub struct CodeSuggestionAdvice<M> {

crates/pg_diagnostics/src/advice.rs

@@ -18,7 +18,7 @@ use termcolor::NoColor;
 ///     message: MessageAndDescription
 /// }
 /// ```
-#[derive(Clone, Deserialize, Serialize)]
+#[derive(Clone, Deserialize, Serialize, PartialEq)]
 pub struct MessageAndDescription {
     /// Shown when medium supports custom markup
     message: MarkupBuf,