Showing posts with label testing. Show all posts
Showing posts with label testing. Show all posts

NLog for Flexible Application Logging in .NET

As much as I have enjoyed working with log4net in the psat NLog works much more seamlessly for .NET apps (it has good, solid abstractions)

From Nuget Package Manager, you can find and reference NLog and the accompanying NLog.Config which simplifies setup. To configure NLog logging, simply point the required properties (you need at least a logFile variable, a target and a rule to get started) to your desired values in the config file that NLog.Config creates in your project root  (NLog.config):

Configuration:

 <?xml version="1.0" encoding="utf-8" ?>  
 <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
    xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"  
    autoReload="true"  
    throwExceptions="false"  
    internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log">  
  <variable name="logFilePath" value="C:\NLog\IDG.log" />  
  <targets>  
   <target name="logfile"  
     xsi:type="File"  
     fileName="${logFilePath}"  
     layout="${longdate}  LEVEL=${level:upperCase=true}: ${message}"  
     keepFileOpen="true" />  
  </targets>  
  <rules>  
   <logger name="*" minlevel="Info" writeTo="logfile" />  
   <logger name="*" minlevel="Warn" writeTo="logFile"/>  
  </rules>  
 </nlog>  
This example uses a log file target in C:\NLog directory; you can utilize a wide variety of logging targets to broadcast app errors

Source Code:

 using Microsoft.VisualStudio.TestTools.UnitTesting;  
 using NLog;  
 namespace ExtRSTests  
 {  
   [TestClass]  
   public class NLogTests  
   {  
     private static Logger logger = LogManager.GetCurrentClassLogger();  
     [TestMethod]  
     public void TestLoggerToFile()  
     {  
       logger.Warn("Something in the app happened that may indicate trouble ahead....");  
       logger.Error("Uh-oh. Something broke.");  
     }  
   }  
 }  
With the logging levels, log formatting (timestamps) and abundant integration options, NLog is a complete logging solution

With NLogger you can implement logging for an array of targets including file, email, database and 3rd party integrations (ie. send message to Slack channel if logger generates any "Error" or "Fatal" level log message).


Reference: https://www.infoworld.com/article/3144535/how-to-work-with-nlog-in-net.html

TDD in small, digestible chunks

Test-Driven Development becomes (necessarily) much more common as code bases grow larger, diverse and more mission critical. Every piece of logic that can be explained in your software's documentation should be testable.

Write the tests, then write the code to meet those conditions, refine, repeat

Though 100% code-coverage is rarely attainable, the closer to fully covered with unit and integration tests, the more secure and solidly structured the code will be. Moreover, the dependency nightmares that many teams wrestle with will be largely mitigated as code reliability checks take place daily when TDD is fully embraced and implemented well.

I am assuming you know the basics of "why" and "how" TDD is done. If TDD does not feel natural, you may want to check out the book Test-Driven Development by Kent Beck. Reading that, what was most impressionable to me and has aided my TDD development style are the following quotes:

"Return a constant and gradually replace constants with variables until you have the real code". -on testing complex functions or objects
 
 "Write tests you wish you had. If you don't- you will eventually break something while refactoring". -on code bases with limited test coverage.

Do not write a few large tests to evaluate multiple ideas/functions at once. Write many small tests that test something that can be said in one short sentence: "Password Reset form successfully sends Reset email to appropriate user".




Write all the tests you know you will need and the tests you wish you had. You will wind up with quite a lot of code, but also quite a lot of "proofs", and you will be able to more confidently add to and refactor your highly-maintainable TDD-developed code.