Understanding how hypervisors work is key to setting up a test lab on a home server. In this article, read about lessons I learned setting up a VM test lab on Unraid.
I put together a very basic website called TestDrivenJSDev.com as a companion for my presentation at HDC (Heartland Developers Conference). The website was not very easy to maintain, in order for me to make a simple grammer fix I had to do a full push up to BitBucket, which would kick off the build process to rebuild the whole site. Not very ideal. But it was temporary, so I lived with it. My big push was really getting the content up there for the HDC presentation.
At the same time I was looking at moving my personal onto a different provider and find a better domain name that reflected my major passions. I wanted to wait until the dust settled on my personal site. Then I would move TestDrivenJSDev.com over to my personal site. Well the time has finally come.
All the existing "lessons" I put together have been ported over. You can find them here:
- Lesson #1 - Common Test Driven JS Problems
- Lesson #2 - Use JSON Objects
- Lesson #3 - Dependency Injection
- Lesson #4 - Test Driven AngularJS
We, as developers, need to ensure our users are getting the best experience possible. Our users are the reason our websites exist. Asking our users to work in classic ASP.NET web forms is just not going to fly anymore.
That means more and more business logic needs to be pushed out of the back end and into the front-end. Not too long ago all of that logic was manually tested. If we were lucky a QA person or group of people would handle all that mind-numbingly boring testing. If we weren’t lucky we had to do all the testing ourselves. Manual testing will always lead to something being missed. Hopefully the bug missed is not something which results in a phone call at 2 AM.
Tooling and good practices has made it very easy to test the C# or Java code since the early 2000s. The good practices helped structure the code which made it easier to test. Following best practices meant putting code to hit the database in a separate class or project than the code that validates the data.