tenacom / aaalib Goto Github PK

Affected version(s)

1.0.1-preview

Regression?

NO - This is a new bug

Context

Static pages in docs still have their default contents from DocFx template.

Expected behavior

The following files should contain something that at least makes some sense:

• docs/index.md
• docs/apidoc/index.md
• docs/articles/intro.md

Actual behavior

The above-mentioned files still have their default contents. 🙈

How to reproduce

Build and serve documentation:

dotnet cake docs.cake --target All

Then open a browser on localhost:8080.

Configuration

Configuration is not important for this issue.

Other information

Writing this was a sub-optimal experience. We need a template for documentation-related issues.

Reference version

2.0.1-preview

Background and motivation

If we want procedures like testing and coverage, once implemented and tested here, to be suitable for at least the majority of real-world projects, we need some "real" code to test.

For starters, there is no meaningful way to "arrange, act, assert" when testing parameterless methods that always returns the same constant. But it's more complex than this. We should be able to meaningfully test Coverlet exclusions, determine whether we need some sort of per-project testing customization vs. a one-size-fits-all default.runsettings file, and the list grows longer with each hour I spend on this.

Proposed enhancement

AaaLib should contain some real-world, or at least real-world-like, code.

It should also contain different kinds of projects:

• a multi-target, multi-platform library - currently the only kind of project AaaLib contains;
• a console executable that uses all possible Microsoft extensions (hosting, logging, command line, file systems, etc.);
• an analyzer and a source generator (maybe in the same project);
• given the latest direction we are taking with regard to user interfaces, an Avalonia application (complete with setup for all necessary platforms) seems to be good to have too;
• ...did I forget anything? I'm almost sure the picture is not complete yet.

Once we have projects of different kinds to work on, we will also be able to add e.g. integration tests as briefly suggested in #10.

Implementation proposals

Code can be brought in from tutorials found on the web, at least initially.

Also, with all due respect to the late Douglas Adams, the Aaa class has to go. It was good as a first, minimal example to start building Cake scripts and GitHub workflows, but once we have "real" code, it has no place here any longer.

Usage examples

n/a

Risks

Of course the removal of the Aaa class is a breaking change. I don't expect much customer impact, though, as AaaLib was never meant to be actually used as a dependency.

Additional information

No response

Reference version

1.0.1-preview

Background and motivation

We all know how important the Answer is.

As a matter of fact, the team here has already gone to great lengths to provide every user with the Answer: we can get it in binary form simply by calling Aaa.GetTheAnswer(), or even as Italian text with Aaa.GetTheAnswerInItalian().

What's missing IMHO is a method to retrieve this essential piece of information in Spanish. Spanish has a lot more speakers than Italian, so a GetTheAnswerInSpanish method would allow applications to support a much greater number of users.

Proposed enhancement

Add to the Aaa class a method (probably called GetTheAnswerInSpanish) that returns the Answer in Spanish.

Implementation proposals

The implementation could be similar to GetTheAnswerInItalian. Namely:

• use a constant for the actual value returned;
• return a string on older frameworks and a ReadOnlySpan<char> on frameworks with span support.

Usage examples

Given this code:

Console.WriteLine(Aaa.GetTheAnswerInSpanish());

the console output should be:

Cuarenta y dos

Risks

I don't see any risks potentially arising from this improvement, as existing code would not be modified and the new methods, if correctly implemented, shouldn't present any particular security risk.

Additional information

I have nothing else to say, but hey, this form won't test itself, right?

Reference version

1.0.60

Background and motivation

The decision had already been taken in Tenacom that C# 11 features are well worth the switch to a non-LTS SDK at a company level. .NET 7 became generally available yesterday, so it's time to take action.

While updating PolyKit and L.o.U.I.S. to the new SDK, I noticed that Microsoft extension libraries have already ditched the netcoreapp3.1 TFM, about one month in advance of EOL. IMHO this may well be considered a death certificate for .NET Core 3.1.

Proposed enhancement

AaaLib should adopt the new SDK as soon as possible.

.NET 7 should also be added as a target framework and .NET Core 3.1 removed: not because of a technical necessity, but to keep in sync with PolyKit's "optimal TFM list" which is a good starting point for new library projects.

Implementation proposals

This should be just a matter of updating the SDK version in global.json and changing the project's TargetFrameworks.

Usage examples

n/a

Risks

The removal of the netcoreapp3.1 TFM is a breaking change.

Additional information

No response

Affected version(s)

1.0.60

Is this a regression?

NO - This bug also affected the previous version

Context

There are no tests in this repository.

Also, quite obviously, no coverage reports.

Expected behavior

PR checks should include running tests.

The release workflow should, too.

Actual behavior

dotnet test is executed in the above-mentioned workflows, but it does nothing, as there are no tests.

(I'm getting boring, I know.)

How to reproduce

n/a

Configuration

n/a

Other information

AaaLib being an incubator for Tenacom's procedures and internal standards, it's not only a matter of writing tests. Which unit testing library do we use? Do we also use some helper library, e.g. FluentAssertions? Etc.

It's important to have a standard, so people can "jump" between projects and feel at home.

Reference version

2.0.1-preview

Background and motivation

See #17

Proposed enhancement

Add a console executable project (AaaConsole?) that uses AaaLib and as many Microsoft extensions as possible: logging, hosting, command line...

No functional specs here: keep it simple, but try to integrate as many extensions as possible so it may become a usage example.

Implementation proposals

Use your imagination 😄 just don't do anything too useful, so it may be changed liberally in the future.

Usage examples

n/a

Risks

n/a

Additional information

No response

Reference version

2.0.1-preview

Background and motivation

See #17

Proposed enhancement

A possible addition could be a simple Calculator class with methods like Add, Subtract, etc.

Viable places to look at for additions may be articles about unit testing, C# tutorials, etc.

Implementation proposals

Just some quick guidelines:

• Don't add anything involving UI and/or I/O.
• Add a dependency to PolyKit.Embedded to test how coverage tools etc. react to it;
• Only other allowed dependencies (at least for now): Microsoft extensions, Microsoft polyfills (System.Memory etc.), plus our own L.o.U.I.S. as soon as it is released.

Usage examples

n/a (depends upon the actual additions)

Risks

As already pointed out in #17, the removal of class Aaa is a breaking change, but no one is going to complain about it.

Additional information

@ric15ni I'm fine with the same PR closing this issue and #10 together.

Reference version

2.0.1-preview

Background and motivation

See #17

Proposed enhancement

Add a source generator with complete integration tests.

Implementation proposals

It should be an incremental generator (of course!) and use as many features as possible: MSBuild properties, MSBuild items, attributes...

The generated code should be well-behaved of course.

Integration tests should consist of simple example projects using the generator, plus test projects that have to build and execute successfully the example projects using MSBuild APIs.

Usage examples

n/a

Risks

n/a

Additional information

No response

Affected version(s)

2.0.15-preview

Is this a regression?

NO - This bug also affected the previous version

Context

When a test project is multi-target, VSTest generates multiple subdirectories under TestResults, each with its own coverage report.

Expected behavior

The result of merging all coverage reports is uploaded to Codecov.

Actual behavior

Coverage reports are not merged and only one of them is uploaded to Codecov.

How to reproduce

Run either build-test-pack or release workflow when a test project is multi-target. Verify that, if there is some code that only runs for one of the targets, coverage never reaches 100%, even though the test project actually covers 100% of the library code.

Configuration

n/a

Other information

No response