![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQqmDYkVlqHj4aHaS3k42CTW8aQhGl-EnOkC6tC79FrceAkmCsos0fcugKWTY8Pw4d9aS5I7Y7VHhlZiWBO02LAH13KfQFkv84CQsna3RpgxJRPc5vu-5eiIAV3t2v6CDlm-eKc5bzHWAR5EqQLP3YQ0IoXnzT-at6QlHlZ3uKeKBWwlVzjZAtF52YQeo6/s16000/audit_testing.png)
Abstract
An automated software testing technique is presented which spares us from having to stipulate our expectations in test code, and from having to go fixing test code each time our expectations change.
An automated software testing technique is presented which spares us from having to stipulate our expectations in test code, and from having to go fixing test code each time our expectations change.
In this paper I put forth the proposition that contrary to popular belief, 100% code coverage can be a very advantageous thing to have, and I discuss a technique for achieving it without excessive effort.
What is the most important quality of software?
Correctness, they say.
And what is the second most important quality of software?
Readability, they say.
That is right, but only in theory.
The term "dependency" is used very often in software engineering, but depending on context, it may mean slightly different things. To avoid confusion, here are the different meanings of the term, and their explanations.
In technical design of software systems as conventionally practiced, call graphs often contain cycles. We show that cyclic call graphs are highly problematic for a number of reasons, the most important being that they require careful handling on a case-by-case basis by custom-written code, thus preventing the standardization, and therefore the automation, of system assembly. We discuss refactoring strategies for systematically eliminating call cycles, including a universally applicable technique for trivially eliminating a certain common type of call cycle. We conclude that since call cycles can be avoided or eliminated, they can be comprehensively disallowed, thus paving the way for the standardization and automation of system assembly.
In this paper we examine the long-standing need within the Software Engineering Discipline for technical design documents that are authoritative. A design document is authoritative if there exist technical means of materializing it as a running software system, thus guaranteeing that the end result is indeed precisely as described by the design. We notice the scarcity and inadequacy of existing solutions, we look into the difficulties involved in the creation of such documents, and we conclude with some realizations on what it would take to come up with a solution that works.
I recently did this at work, and I decided to document the process here in the form of a how-to guide. Please note that I am not an expert, I am learning as I go along, so there may be mistakes.
Sdk-style project files have existed since net5. The kind of project files we were using before that can now be called legacy-style project files.
Sdk-style project files are necessary if you want to:
I am giving this tool a try at work, and I am encountering a great many problems with it. I decided to publicly document my findings.
I recently did this at work, and I decided to document the process here in the form of a how-to guide. Please note that I am not an expert, I am learning as I go along, so there may be mistakes.
It has been more than a year since I created this question on GitHub Community; a couple of days after that I found the solution by myself, so I answered my own question, and to this date comments keep being added by people who were helped by my post.
When I look at it today, I notice that my answer has this particular style, this grumpy indignation which has become so characteristic of me, after a lifetime of battling with lame software, and even worse, with lame error messages.
I thought I should share this on my blog for posterity.
Here is the link: