Here’s how I’ve always learned to code:
- Write (or change) the smallest amount of code that does something.
- Build. See if the code I typed passes the compiler.
- If it doesn’t, then go directly back to step one.
- Run it.
- Determine if it works the way I expected or if something needs to be added or fixed.
- Back to step one.
Richard P. Feynman Said It This Way
The test of all knowledge is experiment. Experiment is the sole judge of scientific “truth.”
~Richard P. Feynman, Six Easy Pieces, Lectures On Physics
Experiment Your Way To Success
Every bit of code that you write and run ends up being an experiment. Those experiments help you gain knowledge and help you discover the scientific truth of your code. The things you know are the things you’ve coded up and tested.
.NET Development Makes This Easier Than Ever
I’ve always been a manual tester so I would build and run and work through the steps to see if the functionality worked as I expected. However, there are better ways now.
Those better ways will lead you to better code.
What Are the Better Ways?
Here’s what I mean. One of the best things you can do is break the functionality of your app up into reusable pieces. In many cases that may mean added functions and classes to a separate DLL (Dynamic Link Library). That way you can add the library to any other project and have the functionality in that project also.
However, when you put your code into the DLL you can no longer run the code to test it without a EXE project that loads it and accesses the functionality. In that past, that meant building a test-driver app which would load the DLL and exercise it by calling the functions.
It’s much easier to do now, because you can add a Unit Testing project to your app.
Yes, that means that you should start off creating two projects (grouped into a .NET solution) when you create your initial DLL project.
Here are the steps that I’ve worked out for you to make that easier.
| Command | Explanation |
|---|---|
$ mkdir <ProjectName> | Creates outer folder to hold project. |
$ cd <ProjectName> | Change Directory into folder. |
$ dotnet new console -o <ProjectName> | Creates new console app proj. with same name as outer folder. |
$ dotnet new sln | Creates new solution file to reference all projects. |
$ dotnet sln add <ProjectName> | Adds the main console project to the SLN file. |
$ dotnet new xunit -o <ProjectName>.Tests | Creates XUnit test proj & adds all depedencies. XUnit proj folder will look like MyProject.Tests |
$ dotnet sln add <ProjectName>.Tests | Adds Unit Test project to SLN file. |
$ dotnet add <ProjectName>.Tests reference <ProjectName> | Adds a reference to main project (<ProjectName>.dll) into the XUnit test project so it can be referenced. |
$ dotnet test <ProjectName>.Tests | Runs the unit tests in the XUnit project. (Makes sure everything works.) |
Here’s what that looked like when I did this for our project: CpSysInfo
| Command | Explanation |
|---|---|
$ mkdir CpSysInfo | Creates outer folder to hold project. |
$ cd CpSysInfo | Change Directory into folder. |
$ dotnet new console -o CpSysInfo | Creates new console app proj. with same name as outer folder. |
$ dotnet new sln | Creates new solution file to reference all projects. |
$ dotnet sln add CpSysInfo | Adds the main console project to the SLN file. |
$ dotnet new xunit -o CpSysInfo.Tests | Creates XUnit test proj & adds all depedencies. XUnit proj folder will look like CpSysInfo.Tests |
$ dotnet sln add CpSysInfo.Tests | Adds Unit Test project to SLN file. |
$ dotnet add CpSysInfo.Tests reference CpSysInfo | Adds a reference to main project (CpSysInfo.dll) into the XUnit test project so it can be referenced. |
$ dotnet test CpSysInfo.Tests | Runs the unit tests in the XUnit project. (Makes sure everything works.) |
More Details In My Upcoming Book Write Cross-Platform Apps
Once you can create projects like this in .NET you will be much more free to follow the REPL Driven Development and that will mean you can type more code and run more code. That’s how you learn to program.
I’ll provide more details in my upcoming book and in my next blog entry.
