-
Notifications
You must be signed in to change notification settings - Fork 33
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
Added support for test automation #648
Added support for test automation #648
Conversation
christophstuber
commented
Jun 10, 2024
- New NUnit test project BusinessCentral.LinterCop.Test and new folder structure.
- Created a fork of RoslynTestKit by cezarypiatek with support for AL language.
- Added first test cases for rules 0001 to 0019.
- New NUnit test project BusinessCentral.LinterCop.Test and new folder structure. - Created a fork of RoslynTestKit by cezarypiatek with support for AL language. - Added first test cases for rules 0001 to 0019.
This looks really awesome, thank you for contributing this! We’ve lacked the possibility to have automated testing so far, this is of great help for the project. Due to the BCTechDays in Antwerp this week, I’m a bit short on time to check this out right now, but absolutely next week I’m going to have a try on this. |
procedure MyProcedure() | ||
begin | ||
//Comment | ||
[|Commit();|] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like your PR.
I don't have experience with this TestFramework.
Can you maybe explain the pattern of the Test AL Objects.
I don't totally understand this bracket []
pattern.
I think that anyone can profit from an Readme on how to ad new tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The framework is an adaptation of https://github.com/cezarypiatek/RoslynTestKit where I replaced the references to make it compatible with the AL analyzer. The benefit is that you can test minimal examples against single rules without the need to set up a complete AL project.
You can test both positive (a diagnostic should be reported) and negative (no diagnostic should be reported) cases.
There is a test class for each rule that specifies the rule to test and the path to the test files. There can be multiple test files per rule, which are specified in the [TestCase]
attribute. Currently I just numbered them 1, 2, 3..., because I find it hard to come up with meaningful names.
- TestCases
- Rule0001
- HasDiagnostic
- 1.al
- ...
- NoDiagnotic
- 1.al
- ...
- HasDiagnostic
- Rule0002
- HasDiagnostic
- ...
- NoDiagnotic
- ...
- HasDiagnostic
- ...
- Rule0001
The thing with the [||]
also comes from this framework. You mark the start and end of where the diagnostic should be reported in the code. Theoretically the framework also can work with line numbers, which is less precise, or TextSpan
, which is more precise, but requires counting characters. I found the [||]
to be both precise in specifying the location and very easy to read and write.
I will try to include an updated readme until end of the week.
Hi @christophstuber, I'm struggling to resolve these conflicts and add them to this PR somehow. Do you mind to do a merge from the pre-release branch into this PR? |
…rerelease' into TestAutomation
@Arthurvdv Conflicts should be resolved now. I also added some more tests up to rule 0032. @pri-kise Also added a new section to the readme. |
@christophstuber Awesome, and again thank you for contributing! |
Hi @christophstuber, thanks for contributing the automated tests. |