Граф коммитов

17 Коммитов

Автор SHA1 Сообщение Дата
Přemek Vysoký fbbd5ceede
[Harness] Move Timestamp and TTY utilities to Helpers (#8138)
Co-authored-by: Premek Vysoky <prvysoky@microsoft.com>
2020-03-18 12:10:25 -04:00
Manuel de la Pena 82bd730ee3
[Harness] Add several fixes to the crash reports. (#8107)
The name of the tests is picked up in a more inner node than
expected. Fwd the test name to make sure that noe all
crashes/timeouts/launches have the same name.
Add extra information when we have a timeout. We want to know the
name and the bot used to ensure that it is easier to identify patterns.
Timeout tests now have:

test title as: App Timeout {AppName} {Variation} on bot {device_name}
message: AppName} {Variation} Test run timed out after {timeout.TotalMinutes} minute(s) on bot {device_name}.
Build issues now have:

test title: App Build {projectTask.TestName} {projectTask.Variation}
That way we know the exact app that failed to build and the exact app that timeout and the device used to run it.
2020-03-13 18:15:02 -04:00
Manuel de la Pena afb11d65cc
[Harness] Add more context to crashes and timeouts. (#8078)
Update the generation of the xml to include a more descriptive title
than "AppCrash". After this commit the name of the testcase and the test
follow this pattern:

- "App Crash {ApplicationName} {Variation}"

This will make it easier to filter since the an example failure will be:

"App Crash Monotouch (Debug)"

Note, the '()' in the example are part of the variation and that is
build by xharness and passed to the runner.

Fixes: https://github.com/xamarin/xamarin-macios/issues/8077
2020-03-11 17:09:21 -04:00
Přemek Vysoký fa7ffbcabc
[Harness] Split out Targets, Utils and remove external links (#8061)
* [Harness] Refactor process management to be testable.

Move all the extension methods to a class. After this refactor, we will
be able to DI the manager in the other classes and assert that the
processes are called with the correct parameters without the need of
launching them.

Also added tests for the manager. We create a dummy console app that
will be executed by the tests. The console app has a number of
parameters that will be used to ensure that the new process behaves as
we want:

- Use the passed exit code.
- Create child proecesses if needed.
- Sleep to force a timeout.
- Writer messages to stdout and stderr.

Our tests call the dummy app and ensures that the results match the
behaviour expected by the dummy app.

* Apply suggestions from code review

Co-Authored-By: Přemek Vysoký <premek.vysoky@microsoft.com>

* Move out utils into a separate namespace

* Move Cache to the test project

* Fix namespaces after merge

* Remove unneeded code

* Move Target files

* Sort csproj

* Refactor Targets

* Rename Cache to TempDirectory

* Fix using

* Move ProjectFileExtensions

* Remove dead code

* Move Extensions

* Add empty StringUtilsTests

* Add StringUtils tests

* Revert refactorings

* Update tests/xharness/Utilities/StringUtils.cs

Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>

* Update tests/xharness/Utilities/StringUtils.cs

Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>

* Add better formatarguments test

* Update tests/xharness/Utilities/StringUtils.cs

Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>

Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Premek Vysoky <prvysoky@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-03-10 13:12:33 +01:00
Manuel de la Pena 169cecfe93
[Harness] Refactor a little the code for logging to simplify testing. (#8021)
Move to use interfaces, that will let us later add tests that will
verify that all the correct logging is performed. As an example, added a
test for XmlResultParser that ensures that the failures are correctly
generated. The test uses Moq to pass the different paths to be used and
later be able to verify the wirtten xml.
2020-03-03 13:59:44 -05:00
Manuel de la Pena dc57f88e9f
[Xharness] We support diff xml outputs. Allow to pass the desired one. (#7971)
We support different outputs, lets add the avility for the caller to
decide which one to use. We default to NUnit V3 due to or dependency to
it in VSTS.
2020-02-27 20:10:48 -05:00
Manuel de la Pena 09c4c80c21
[Harness] Add start-time to work around a bug in the publishing tool. (#7951)
The publishing tool is a little fragile. In run
https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3490479&view=logs&j=67d14776-f827-5fe4-2625-2db4b5987fd1&t=fa262eec-9d97-5ba4-b4cc-a9292beecd8f
I noticed that valid test runs with a failing test (launch issues) were
not being uploaded.

I found out that the reason is a flaw in the logic on the parser of the
publishing tool. The tool assumes, that if there is no start-time, there
are no test results (do remember that NUnitV3 is schemaless we don't
know exactly what attrs are compulsory).

The culprint is line: https://dev.azure.com/mseng/AzureDevOps/_git/AzureDevOps?path=%2FTa%2FTasks%2FPublishTestResults%2FParser%2FNUnitResultParser.cs&version=GBmaster&line=473&lineEnd=473&lineStartColumn=63&lineEndColumn=64&lineStyle=plain

Basically:

```csharp
 if (testRunNode?.Attributes?["start-time"] != null) {
   // import test data
 }

 // do nothing interesting since there is no data
```

This commit fixes it by setting the start time as the current one, we
dont care since it is a failure xml result.
2020-02-21 14:00:14 -05:00
Manuel de la Pena ca26ef62d5
[Harness] Close message element correctly in NUnit3. (#7946)
Xml should be:
```
<failure>
  <message>Foo</message>
  <stack-trace>Bar</stack-trace>
</failure>
```

But we generate:

```
<failure>
  <message>Foo
    <stack-trace>Bar</stack-trace>
  </message>
</failure>
```

Makes the parsing of the failures impossible.
2020-02-20 11:15:57 -05:00
Manuel de la Pena 8f58afe857
[Harness] Add a prefix to the final xml to be imported. (#7914)
Because the PublishTest task is taking a regular expression, it is
importing the test results more than one, which gives wrong stats. Add a
prefix to better filter those files we are interested in (thos with
attachments).

As a bonus, refactored the xml failure code for less copy pasting and to
have a single place where we had to add the prefix.
2020-02-17 12:27:22 -05:00
Manuel de la Pena 5475256f51
[XHarness] Close left open html tags. (#7915) 2020-02-17 12:18:31 -05:00
Manuel de la Pena 6fde517698
[Harness] If app does not launch or crash, create a test failure. (#7906)
Make sure that when we are running on VSTS we do get test failures when
the application cannot be launched or crashes.
2020-02-14 17:27:01 -05:00
Manuel de la Pena f41a64fd29
[Harness] Attach build logs to NUnit V3 xml results. (#7855)
Get the previous task ID and use it to build the log directory of the
builds, then add all the combined files as attachments.

Fixes: https://github.com/xamarin/xamarin-macios/issues/7854
2020-02-13 16:51:14 -05:00
Manuel de la Pena 2cfc456787
[Harness] Add code that will generate custom xml results with failures. (#7874)
There are two cases that are not currently considered in VSTS that we
need to report:

1. The application could not be built.
2. The application crashed.

In those cases we do not have xml to be imported by VSTS. What we are
going to do is create 'fake' test runs that will encapsulate a build
error or a crash to be imported by VSTS with the needed attachments.

This code just writes custom errors. The generated results are like the
following:

* [NUnit V2](ihttps://gist.github.com/mandel-macaque/7207f6acb5a90895adf84f40a05e0b21)
* [NUnit V3](https://gist.github.com/mandel-macaque/99898c0570cde2e54e38d8af5991f824)
* [xUnit](https://gist.github.com/mandel-macaque/4591cc06d3db0e46de6a0bf886804f13)
2020-02-12 22:06:24 -05:00
Manuel de la Pena 1a0b2bbcc0
[XHarness] Generate TestReorts for NUnit V3. (#7851)
Now that we have NUnit V3 xml results, do generate the test report for
those correctly.
2020-02-11 20:28:28 -05:00
Manuel de la Pena be9a8b1e81
[XHarness] Add logs to VSTS test runs. (#7844)
As per the documentation of the VSTS test uploader (https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-test-results?view=azure-devops&tabs=yaml#attachments-support)
the tests support the addition of attachments. We want to be able to
access the logs of the different tests runs, this is achieved the
following way:

1. Move TouchUnit to use NUnit V3 which allows to add attachments.
2. Once the tests are ran, add the attachments to the following nodes:
   1. The very first test-suite. This will allow to have the logs for
   succesul tests.
   2. Add logs to failing tests. Reduces the number of clicks to be done
   to access to the logs when a test case fails.
3. Modify the assembly name of the test-suit to match the name of the
application. This ensures two things.
   1. We have a consistent name for the file column in VSTS, that can be
   used to see recurrent failing tests.
   2. The name is more readable, since if not, it will contain the UUID
   of the device.

Logs are not added to succesful tests because it will have the following
problems:

* Larger data storage usage.
* Longer upload time. The addtion of the logs per tests (succesful or
failed) was tested and resulted in an upload time LONGER than 6 hours
for all TouchUnit, NUnit blc tests and xUnit bcl tests.

In order for this to be useful, the task in the pipeline SHOULD NOT
merge test runs. We should have a test run PER application so that we do
not mix the logs.


Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-02-11 14:03:16 -05:00
Manuel de la Pena 072c262b9b
[XHarness] Do write the TestReport when we have xUnit results. (#7835)
Add code to write the TestReport when we have xunit results. Also
refactored code for the NUnit format to not use LINQ, it will use less
memory and in the future we can move to async (not now since it might
raise other problems).

fixes: https://github.com/xamarin/xamarin-macios/issues/7826
2020-02-10 21:44:33 -05:00
Manuel de la Pena fe2b014d6a
[XHarness] Refactor xml code to make the AppRunner class cleaner. (#7794)
There is a lot of logic related to xml in the AppRunner making it more
complicated than needed. Move the methods to a hlper class.
2020-02-05 21:23:44 -05:00