Tuesday, November 28, 2023

One test is never enough!

One part of creating coded tests for software is being able to know when something doesn't work as it should, not just confirming that something does work as expected. 

Imagine if you didn't. Consider a test that tries to verify that given X input you get Y output.

If you write a single test for this, you might be confident that when you input X, you do get Y out.

But, what if you input Z and still get a Y out when you shouldn't?

You probably also need a test for Z input too.

Actually, even having two test cases probably isn't enough.

If you're testing more than a simple boolean input, there are a lot more cases that you should probably be testing too.

I thought this went without saying.

I guess not. 

So now, I've said it.

Thursday, November 23, 2023

This looks like a NuGet bug - but isn't

Error NU1301 The local source '[PATH]' doesn't exist.

I recently reported a bug where I was trying to use an updated version of a NuGet package. When I specified a new version of that package (in Directory.Packages.props), I got build errors complaining about a path to another project in the solution.

I got the error message shown above, but the path was relative to another project in the solution.

Very odd.

Why would the newly updated package version do anything with the referenced path?

It turns out it didn't.

But, it took me two days, and then the answer popped into my head while walking back from the shop, to explain what was happening.

A couple of days earlier I'd been testing the package created by another project in the solution.

To do so, I'd created a local package source that pointed to the output path of that project. [Those of you paying attention will have already guessed that this is also the path from the error message that started all this.] Then in a different solution, I could load my test project and add a reference to the package I'd built for testing.

All was good. I tested that package and carried on with my work.

Here's an example of the package source I created for testing. [Ignore the parts that are obscured. They're not relevant.]

See the path I'm setting in the image: "c:/source/MyProject/Release".

The Package Sources Window - showing a custom configured source
If this path doesn't exist when creating (updating) the source entry you get a helpful error message:
Package Manager Options - The source specified is invalid. Please provide a valid source.

That's a good, clear error message. It clearly makes known what's wrong.

Now, guess what happens if that path exists when the source is created but is later deleted.

It's a reasonable scenario. Create a local package source for testing and then later delete the directory when testing is finished.

Or rather than explicitly delete it, maybe you reset a branch, and that causes the path to be deleted.

That's what I did.

Then, a few days later I try and add a version of a package I've never used before.

And that's when I got the error.

So, what's going on?

Well, what I assume is happening is that before downloading a new version of the package, it checks all the configured sources to see if it exists in any of them. It (the download manager) doesn't know that the package only exists on nuget.org and quite rightly checks all configured options before downloading something again unnecessarily.

Except, in my situation, it's now trying to look in a directory that no longer exists which causes an exception.

There's an argument that it might be good to add an option to ignore local sources that don't exist but I expect that to be likely to also cause a number of obscure exceptions that aren't obvious to diagnose.

I expect if I had tried to use the UI to update the package version rather than directly editing the props file I'd have got a different (and probably more helpful) error message. - [Actually, I've just checked and  it's the same error message but seeing that I'm using ALL Package sources may have helped me spot what's wrong.]

So, not a bug in the package I was trying to use, and not a bug in the projects that reference that package.

If anything, this is just a limitation of options for testing a package locally and poor error messages.

Or it's me being an imposter for thinking I knew how to use Visual Studio and NuGet. 

Or, it's me being stressed and making silly mistakes with configuration.

Or, it's another reason for someone to complain about my code. There's been a lot of that recently. :(

Or maybe it's a reminder for all of us to only keep local NuGet package sources enabled while they're needed.

Saturday, November 18, 2023

Review: Learning WinUI3 (2nd edition)

I bought a physical copy of the first edition.
I was given an electronic copy of this (2nd) edition.

I twice tried to post a review on Amazon but they refused it based on unspecified "community guidelines".
Here's what I tried to say:

Probably the best book available on learning to develop with/for WinUI3. 
This updated version provides a comprehensive introduction to WinUI3 development and the broader required knowledge to help gain a firm grounding in its use.
The new and updated chapters help keep the book relevant with a platform and ecosystem that has evolved since the release of the first edition.
If you want to learn about WinUI3 from a book (rather than videos, etc.) then I recommend this one.

Monday, October 30, 2023

Rethinking "code-adjacent" talks

I've been thinking about the talks people give at technology conferences and user groups.

Not the ones that explain, "Here's a specific technology," or "Here's how to use a certain API," or even "Here's how to create an API."

I'm thinking more about the ones about less specific subjects. Topics like choosing between design patterns, thoughts about ways of working, project organization, communication, prioritization of tasks, who should do what, and the like.

I'm not sure of a universally understood term for these things, but let's use "code-adjacent" to talk about things related to the code (and the way we write it) rather than the code itself.

These topics are never purely objective but are highly influenced by context and subjective opinion.

And now we get to the idea of giving talks on these subjects.

I recently attended a conference with many such talks, and it struck me how popular these types of talks have become and how easy it is for presenters to accidentally treat opinions as fact or their experiences as universally true.

[I waited a few weeks after the conference before posting this to try and avoid direct criticism of individuals.]

I suspect many people listening to these talks didn't know or notice where the speaker was doing this.

At the conference where I started thinking about this, I heard:

  • Questionable opinions being passed off as absolute facts.
  • "Facts" that were demonstrably false.
  • Broad dismissal of topics that the presenter acknowledged they didn't enjoy or understand in detail.
  • Things that are true in the speaker's limited and highly specialized experience being taught as always true in all circumstances.
  • A detailed discussion of scenarios that may have been relevant 10 years ago but which modern tooling, techniques, and best practices make redundant. 

 I wonder how many attendees (especially less experienced ones--there were many students in attendance) left, not realizing there was a lack of nuance expressed in what they were told.

These talks are often also shorter, so have less time for questions or clarification. The talk ended when it got to the end of the time allocated, and then everyone filtered off to other rooms for subsequent talks.

As an attendee, I want the best, most up-to-date, fact-checked information from experts.  Or, I want people to share their opinions and experiences while clearly justifying and explaining these.

As a (sometimes) organizer, I want speakers who have thought out, planned, checked, and verified what they will say. I don't want speakers who will do the bad practices mentioned above. I want the best for the attendees. I don't want them to say, "That was a bad speaker," because that quickly becomes, "That event doesn't get good speakers," or "I was given bad advice or incorrect information at that event--and so won't go back." 

As a speaker, I know it's all about the audience and giving them the best information in ways that will help them remember and be able to apply the knowledge I'm sharing. I get the impression from some speakers that they think they are the experts and must be right as they are the ones talking from the front, and so no one else matters. (Basically, they make it about themselves rather than the audience.)

What if these talks were done differently?

What if talks of this nature had (at least?) two different speakers. Ideally, with very different experiences and opinions.
Maybe they do the talk together.
Maybe they do shorter talks back to back.
Maybe one gives a talk, and the other has time at the end for rebuttal or clarification or to give counterpoints or counterexamples.
Or, maybe you can't get more than one expert on a subject, so you get a small group of senior, experienced, and broadly knowledgeable people to lead questions and clarifications at the end.

Will this be more work? Possibly.

But wouldn't that give a much better experience to attendees?

But what if the presenter is worried about being contradicted or having their errors pointed out?

Well, do you want speakers who have that attitude?

Do you want the audience to be given bad or incorrect advice?

As a (sometimes) speaker and presenter, I want to know if the information I'm giving is incorrect, outdated, easily misunderstood, or otherwise wrong. I want to know for myself, and I want to know for the people who will hear what I say.

I'm currently planning and preparing a talk on the importance and value of documentation and testing for software developers. It's potentially challenging (to hear) and will contain much that is highly subjective, but I think it's very important, and I have valuable advice to share on the subject.

I'm not yet at the point where I'll welcome criticism and objections to what I have to say, but I know that there are people with different opinions, and I want to know and acknowledge these.

A talk that's just "These are my thoughts on this subject." is far less valuable than "Based on these experiences, I have these thoughts about this subject, and this is why it could be useful for you to know."