-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/main' into feature/telemetry
- Loading branch information
Showing
1,311 changed files
with
58,737 additions
and
1,503 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| testDirectory: ../tests |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,12 @@ | ||
| **/.ai/data/* | ||
| **/.pyenv/** | ||
| **/.vs/** | ||
| **/.vscode/** | ||
| **/bin/*/net6.0/* | ||
| **/bin/*/net7.0/* | ||
| **/bin/*/net8.0/* | ||
| **/obj/* | ||
| **/Properties/launchSettings.json | ||
| ideas/website/node_modules/** | ||
| testresults/** | ||
| *.user | ||
| **/launchSettings.json | ||
| *.user |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # Contributing | ||
|
|
||
| This project welcomes contributions and suggestions. Most contributions require you to | ||
| agree to a Contributor License Agreement (CLA) declaring that you have the right to, | ||
| and actually do, grant us the rights to use your contribution. For details, visit | ||
| https://cla.microsoft.com. | ||
|
|
||
| When you submit a pull request, a CLA-bot will automatically determine whether you need | ||
| to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the | ||
| instructions provided by the bot. You will only need to do this once across all repositories using our CLA. | ||
|
|
||
| This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). | ||
| For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) | ||
| or contact [[email protected]](mailto:[email protected]) with any additional questions or comments. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5 changes: 5 additions & 0 deletions
5
ideas/cool-helper-function-scenarios/NutritionHelperFunctions.cs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5 changes: 5 additions & 0 deletions
5
ideas/cool-helper-function-scenarios/PokemonHelperFunctions.cs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,174 @@ | ||
| You | ||
| show me a sample pytest reporting xml file output | ||
|
|
||
| Assistant | ||
| Sure, here's a simplified example of a potential XML file output from Pytest using JUnit-style reporting: | ||
| <?xml version="1.0" encoding="utf-8"?> | ||
| <testsuite name="pytest" tests="5" errors="1" failures="1" skipped="0"> | ||
| <testcase classname="test_module" name="test_pass" time="0.1" > | ||
| </testcase> | ||
| <testcase classname="test_module" name="test_fail" time="0.1" > | ||
| <failure message="Failing test" type="type_error">Traceback (most recent call last): Test `test_fail` failed with AssertionError</failure> | ||
| </testcase> | ||
| <testcase classname="test_module" name="test_error" time="0.1" > | ||
| <error message="Error in test" type="type_error">Traceback (most recent call last): Test `test_error` error out with TypeError</error> | ||
| </testcase> | ||
| <testcase classname="test_module" name="test_skip" time="0.1" > | ||
| <skipped message="Skipped test" type="skip_error">Traceback (most recent call last): Test `test_skip` skipped with unittest.SkipTest</skipped> | ||
| </testcase> | ||
| <testcase classname="another_test_module" name="test_pass" time="0.1" > | ||
| </testcase> | ||
| </testsuite> | ||
|
|
||
| This file provides a summary of the test results, including the number of tests run, number of errors, failures, and skipped tests, as well as detailed information about each individual test. | ||
| Please note that the actual contents can greatly vary depending on the complexity of your tests and configuration of your Pytest. | ||
|
|
||
| You | ||
| is testsuite always the root? | ||
|
|
||
| Assistant | ||
| Yes, in JUnit-style XML reports, the <testsuite> element is generally the root. It represents a series of test cases (represented by <testcase> elements) that together form a test suite. | ||
| However, if you generate the report with pytest's --junit-prefix option or you're running the test within a suite of test suites, the report might include a wrapping <testsuites> element: | ||
| <?xml version="1.0" encoding="utf-8"?> | ||
| <testsuites> | ||
| <testsuite name="pytest" tests="5" errors="1" failures="1" skipped="0"> | ||
| <!-- test cases here --> | ||
| </testsuite> | ||
| <!-- potentially more testsuites here --> | ||
| </testsuites> | ||
|
|
||
| In this case <testsuites> is the root node, containing one or more <testsuite> elements. | ||
|
|
||
| You | ||
| ok. under testsuite, is testcase the only valid child? | ||
|
|
||
| Assistant | ||
| Primarily, yes, the <testsuite> tag in a JUnit XML report contains a series of <testcase> elements. Each <testcase> element represents one test. | ||
| However, <testsuite> can also have a few other types of children in addition to <testcase>. These additional child elements provide metadata about the suite as a whole or report on issues that affected the suite rather than individual tests. | ||
| These additional tags include: | ||
| <properties>: A collection of properties, or environment data, which applies to the entire test suite. This is usually used to store information relevant to the environment where the tests were run. | ||
| <error>: Indicates an error that prevented the test suite from running to completion. This tag is not associated with an individual test case. | ||
| <system-out> and <system-err>: These capture text that was sent to standard output or standard error during test execution. This can include logs or debugging information. | ||
| Here's a simplified example: | ||
| <testsuite name="pytest" tests="5" errors="1" failures="1" skipped="0"> | ||
| <properties> | ||
| <property name="exampleProperty" value="exampleValue"/> | ||
| </properties> | ||
| <testcase classname="test_module" name="test_pass" time="0.1"/> | ||
| <!-- additional testcases here --> | ||
| <error message="Fatal suite error"/> | ||
|
|
||
| <system-out> | ||
| System output text (e.g., logs) goes here... | ||
| </system-out> | ||
|
|
||
| <system-err> | ||
| System error text (e.g., exception messages) goes here... | ||
| </system-err> | ||
| </testsuite> | ||
|
|
||
| Remember that the actual content and structure can vary based on your test configuration and the specifics of your test environment. | ||
|
|
||
| You | ||
| what are all the valid children of testcase? | ||
|
|
||
| Assistant | ||
| In a JUnit-style XML report, the <testcase> element can have several types of child elements. Each one provides additional information about the result or execution of the specific test case. | ||
| Here are the key types: | ||
| <error>: This indicates an error that occurred while the test was running. This is typically used for unexpected problems, such as uncaught exceptions. The message attribute provides a short description of the error. | ||
| <failure>: This indicates that the test case failed, i.e., a test assertion was not met. The message attribute provides a short description of the failure. | ||
| <skipped>: This indicates that the test case was skipped and not run for some reason. This could be because the test was manually disabled, or a setup method failed. This element usually has no content. | ||
| <system-out> and <system-err>: These capture text that was sent to standard output or standard error during the execution of this specific test case. This could be logs or debugging information. | ||
| Here's an example of a testcase element with failure and system-out children: | ||
| <testcase classname="test_module" name="test_fail" time="0.1" > | ||
| <failure message="Failing test" type="assertion_error">Traceback (most recent call last):...</failure> | ||
| <system-out>Some standard output text here...</system-out> | ||
| </testcase> | ||
|
|
||
| Remember that the actual content and structure of these elements can vary based on the specifics of your test configuration and environment. | ||
|
|
||
| You | ||
| tell me all the xml elements, valid parents, valid children, and what are required and optional attributes. | ||
|
|
||
| Assistant | ||
| JUnit XML is a standard to report test results that can be processed by tools that understand the format. Below, you'll find a summary of all XML elements, their valid parents and children, and required and optional attributes. | ||
|
|
||
| <testsuites>: The root element for an XML document representing collection of test suites. | ||
| Parent: None | ||
| Children: <testsuite> | ||
| Attributes: None | ||
|
|
||
| <testsuite>: Represents a test suite which is a collection of test cases. | ||
| Parent: <testsuites> (optional), <testsuite> | ||
| Children: <properties>, <testcase>, <system-out>, <system-err>, and <errors> | ||
| Attributes: name (required), tests (required), failures, errors, skipped, time,timestamp, hostname, id, package | ||
|
|
||
| <properties>: Represents a set of properties relevant to the entire suite. | ||
| Parent: <testsuite> | ||
| Children: <property> | ||
| Attributes: None | ||
|
|
||
| <property>: Represents a single property in the set. | ||
| Parent: <properties> | ||
| Children: None | ||
| Attributes: name (required), value (required) | ||
|
|
||
| <testcase>: Represents a single test case. | ||
| Parent: <testsuite> | ||
| Children: <error>, <failure>, <skipped>, <system-out>, <system-err> | ||
| Attributes: name (required), classname (required), time | ||
|
|
||
| <error>: Represents an error that occurred while the test was running. | ||
| Parent: <testcase>, <testsuite> | ||
| Children: None | ||
| Attributes: message, type | ||
|
|
||
| <failure>: Represents a failure of a test case. | ||
| Parent: <testcase> | ||
| Children: None | ||
| Attributes: message, type | ||
|
|
||
| <skipped>: Represents a test case that was skipped. | ||
| Parent: <testcase> | ||
| Children: None | ||
| Attributes: None | ||
|
|
||
| <system-out>: Captures text that was sent to standard output during the execution. | ||
| Parent: <testcase>, <testsuite> | ||
| Children: None | ||
| Attributes: None | ||
|
|
||
| <system-err>: Captures text that was sent to standard error during the execution. | ||
| Parent: <testcase>, <testsuite> | ||
| Children: None | ||
| Attributes: None | ||
|
|
||
| You | ||
| is that everything? | ||
|
|
||
| Assistant | ||
| Yes, that covers the standard JUnit XML schema in terms of elements, parents, children, and attributes. Please note that since it's a standard, it's generally followed, but some testing frameworks may have slight variations. | ||
| Standard Elements include: | ||
| <testsuites> | ||
| <testsuite> | ||
| <properties> | ||
| <property> | ||
| <testcase> | ||
| <error> | ||
| <failure> | ||
| <skipped> | ||
| <system-out> | ||
| <system-err> | ||
| With their accompanying attributes and nested relationships. | ||
| However, it's a standard and its tooling dependent, some tools may add additional elements or attributes to provide more information about the tests. It's always good to check with documentation of the specific tool you are using. | ||
|
|
||
| You | ||
| in java, how do namespaces show up here, as part of which attribute? | ||
|
|
||
| Assistant | ||
| In a JUnit XML report, the Java package name is typically included in the classname attribute of the <testcase> element. The classname usually contains the fully qualified name of the class, which includes the package name. | ||
| Here's an example: | ||
| <testcase classname="com.example.myapp.MyTestClass" name="testMyMethod" time="0.1"/> | ||
|
|
||
| In this case, com.example.myapp is the package name, and MyTestClass is the name of the Java class that contains the test method. This naming convention allows each test case to be uniquely identified, even if the test method names are the same in different test classes. | ||
| Please note that the way the package or namespace information is included can depend on the testing tool and configuration being used. This is typical behavior but may vary. |
Oops, something went wrong.