Nearing Last Call for PowerShell Summit Topic Proposals (+ Topic Ideas!)

Tue, 06 Sep 2016 14:04:52 +0000

Remember that our Call for Topics is still open until the end of September, if you’d like to submit. And, from our Summit Alumni Slack channel, here are a few things people said they’d like to see…

I would love to see a session on what it takes to build a PKI infrastructure in support of PowerShell operations ( stuff liked passing creds with DSC ) - this is something glossed over all the time as if it is not a big deal but I think it can be quite challenging for a lot of people to implement.
Writing for Performance: Tips and Tricks to Write Faster Code
Compiled cmdlets - how to create them and why you might want to (this got a lot of thumbs-up)
Open source PowerShell hackathon. Either one multi-hour (2, 3, 4?) window where people can break into groups and work on some open source PowerShell extension, or two sessions, one at the beginning of the event and one at the end. The one at the beginning the presenters/organizers provide a set of possible project ideas to work on, and people interested can sign up/vote for projects which creates groups. The one at the end gives groups an opportunity to share/demo what they produced. Having a room where people can gather to work on it would be cool. These don’t have to be big projects. They could be small things, like knocking off one or more issues for an open source project. The end goal is to have a pull request submitted or a new project posted in GitHub or a new module submitted in the Gallery. _Now, to be clear, this isn’t a session - but you can definitely propose it. We have some longer time slots on Wednesday for panels, and this might be something you could do then. _
examples of real world DSC usage - that was a comment I heard from a number of folks this year
Practical Pipelines. ( Illustrate that release pipelines aren’t just for DevOps-practicing shops, or public-facing software )
Build plans (and tools, like psake)
Module design best practices (lots of thumbs-up on this one)
Working with Open Source Projects (as a Contributor)
Working with Open Source Projects (as a Maintainer)
Applying Agile Software Development Methodologies to PowerShell
Using for . (assumption: someone writes the equivalent of inspec wrapped around Pester)

And if you read the above carefully, you’ll notice that **we do also have some space for afternoon panels on Wednesday - so if there’s a group discussion you’d like to lead, propose it! **Just be clear in the description you submit that you’re proposing a panel. It’ll be up to you to recruit panel members, which you can do on-site. We’ll announce panels in need of panelists and direct them to you.

Unit Testing is “Pestering” the Hell Out Of Me

Fri, 02 Sep 2016 17:31:14 +0000

About a week or two before Devops Camp, the attendees were asked how much experience they had using Pester, because another attendee was preparing a discussion on Pester and wanted to gauge the other attendees’ comfort level. Learning Pester had been on my to-do list for a while, but I had procrastinated on it for far longer than I intended. I answered “Beginner” - although “complete and utter newbie” would have been more accurate - and I vowed to spend some quality time looking at Pester before arriving at camp.
There are some really great resources out there devoted to Pester, from beginner to intermediate to way-over-my-head. I read articles and watched videos. And I understood, in a conceptual kind of way, how to use Pester. Describe, Context, It, Mock, Assert-MockCalled – I understood what these things were used for. The examples made sense. I was ready to move on to trying it myself. But here is where I stumbled and recovered, and I would like your feedback and opinions on my discoveries.
I took a piece of code I was currently working on and decided that a small function in that code was the perfect function to attempt my first unit test on. I mean, it was the tiniest little function - 7 lines of code! What could possibly be easier? Right?
Boy, was I wrong. The struggle IS real.
In a nutshell, my function really is 7 lines – an If/Else statement and a For-loop – and inside each is an external call to an Active Directory cmdlet. Those would definitely need to be mocked. After all, we know or assume that Set-ADAccountControl and Set-ADObject do what they are supposed to. I was stumped at where to even start because after mocking these external calls – there isn’t actually anything left to the code!
Even after a wise person told me that “This probably isn’t a great example of a “Pester 101” example”, I was still determined to figure out how to write a Pester test to test this function, but I needed to set aside my thoughts of “I can’t figure out how to write a Pester test for this” and instead, start with “Figure out how to write a unit test for this.” My brain freeze wasn’t about Pester – it was about unit testing. What do I need to test? My next step was to do some reading up on general unit testing concepts.
I’m not opposed to buying a book on testing concepts, but I wanted some quick answers and not a research project just to get me started. I turned to “Dr. Google” and I found some useful definitions, both formal and informal, on what unit testing really is. But it wasn’t until I found a comment buried deep in a StackExchange forum post that I realized what my next steps were.

Red-Green-Refactor-Repeat
Red: Write a test that fails.
Green: Write the simplest code that makes the test pass. For the first pass, don’t handle edge cases, just enough to make the test pass.
Refactor: Clean up the code and optimize if necessary. Make sure the test still passes.
Repeat: Now think about handling those edge cases and repeat the previous steps with tests, then code, to handle them.
The entire thread can be found here and the detailed explanation of the Red-Green-Refactor-Repeat concept in the comments is definitely worth a read:
http://programmers.stackexchange.com/questions/750/what-should-you-test-with-unit-tests

When I started thinking about writing this article, I knew that I was struggling with the concept of unit testing and I had planned to include the code that I was looking to test as part of the blog. After doing the reading to try to wrap my brain around the concepts, I changed my approach. I’ve decided to scrap the original version of this code and try to use the above approach to re-develop the function instead. I plan to blog about my journey through this process in a future post.
Until then, I’d like to initiate a dialog with you, the readers: How do you approach unit testing? What is your thought process? What do you feel is important or not important to include in a unit test?

]]>

Articles from September 2016 on PowerShell.org - Welcome Automaters!

Recap of DuPSUG PowerShell Saturday 2016

PowerShell Happenings at Ignite 2016

Changing of the Guard at PowerShell.org

PowerShell + DevOps Global Summit 2017 Preview

Deep Dive Day

Nearing Last Call for PowerShell Summit Topic Proposals (+ Topic Ideas!)

Unit Testing is “Pestering” the Hell Out Of Me

Articles from September 2016 on PowerShell.org - Welcome Automaters!

Recap of DuPSUG PowerShell Saturday 2016

PowerShell Happenings at Ignite 2016

Changing of the Guard at PowerShell.org

PowerShell + DevOps Global Summit 2017 Preview

Deep Dive Day

All Together Now

Breakout!

Par-ti-ci-pa-tion

On The Air

Networking

Extra Bits

Mark Your Calendars