In the previous post, I discussed unit testing of my Visual Studio extension for generating documentation comments. This post continues the discussion about testing by looking at integration, system, and acceptance testing.
While I will eventually be writing a large amount of code for this project, the project itself is very contained in where it integrates into Visual Studio. That is, there will be one menu item that executes the code. In my post, Testing, 1, 2, 3, I provided the following definitions:
- Integration tests validate the interfaces and interactions between components. These are black or gray box tests.
- System tests validate that the integrated system meets specified requirements. These are black box tests.
The integration tests definition mentions interfaces. Does that mean UI interfaces? Do I need to be selecting the menu item for each integration test? Read more ›
I have discussed testing in several posts and also the creation of a documentation comments generator over the last 5 posts. This post and the next one will bring the two topics together. That is, I will be discussing how to test the generator.
In the post, Testing, 1, 2, 3, I gave the four levels of testing as unit testing, integration testing, system testing, and acceptance testing. I will discuss what testing I do for each of these. This post is limited to discussing unit testing. Read more ›
There are two tools which I have found to be invaluable as I develop my documentation comments generator. These tools are the Syntax Visualizer, and RoslynQuoter.
Syntax Visualizer is a Visual Studio extension that is installed as part of .Net Compiler Platform SDK. To view the Syntax Visualizer, click on View->Other Windows->Syntax Visualizer in Visual Studio. The syntax visualizer window opens and displays the syntax for the code in the active editor window. Here is what the syntax visualizer looks like: Read more ›
In the last post, Creating A Documentation Comment Generator For C#: Setting Up The Framework, I discussed a framework for analyzing the source code and generating documentation comments. I mentioned that three steps are involved:
- Retrieve the source code for the active document.
- Modify the source code to contain the documentation comments.
- Replace the source code in the active document with the modified source code.
I showed all of the code necessary for steps 1 and 3. The code for step 2 was also shown and is repeated here:
var syntaxTree = CSharpSyntaxTree.ParseText(code);
var root = syntaxTree.GetRoot();
var rewriter = new DocumentCommentsRewriter();
var newCode = rewriter.Visit(root).ToFullString();
code contains the source code that was retrieved from the active document, and newCode is the source code modified to contain the documentation comments; it is the code that is written back to the active document. That’s all there is to it! The source code analysis and generation of the documentation comments occurs in the DocumentCommentsRewriter class. This post will look at the contents of that class.
Read more ›
I first discussed a documentation comment generator by listing a number of user stories for it in I Was Doing It All Wrong, And How I Changed To Doing It Right! In the post, Creating A Documentation Comment Generator for C#: High-Level Design Decisions, I discussed various ways of generating documentation comments. In that post, I stated that I wanted to create a Visual Studio extension that adds a menu item to the Tools dropdown menu. When the menu item is selected, documentation comments should be generated for the active file (the file in the Visual Studio editor window). This post will look at setting up the framework to do that.
Read more ›
A few of weeks ago, I wrote a post about free software for documenting C# API’s. In that post there is a mention of two documentation comment generators: built in capabilities in Visual Studio, and GhostDoc. In this post, I will investigate building a documentation comment generator with the ultimate intent of creating a generator with greater capabilities.
Read more ›
When I was working, my coworkers and I used the waterfall model for developing large projects. That meant that a very large portion of a project was spent first gathering user requirements and then creating a detailed design before a line of code was written.
For home projects, especially after I retired, I would do it all wrong. I would often jump into programming (the fun stuff) with little time spent on the requirements and design Many of you do the same, especially if you are new to programming. That is like this old joke: Read more ›