Here is my very notey response, mostly based on my experience as (a) participant at Hack Manchester (RIP) and (b) being a judge myself at various different events over the years.
Think about the comfort of the participants – both physical and emotional.
How can you be welcoming and supportive?
Give them the opportunity to solve real-world problems but with a lot of scope for creativity.
Give them a choice of different challenges.
Don’t expect judges to do full code reviews (too time consuming) – judge by presented results instead.
Ask participants to present their results in an easy to digest format (to streamline the judges’ job).
Let people present vision as well as working results (it’s hard to get things fully functional in a short space of time).
Recruit helpers to give a hand when participants are stuck.
When recruiting helpers, emphasise they do NOT have to know all the answers. Their job is to help people seek solutions, not provide solutions themselves.
Have a v strict time limit for final presentations. How many teams do you have? How long will presentations take overall if (eg) you give them 2 mins each and allow extra for changeovers? Is that too much?
You’ll be surprised how much people can present in even 1 min. Let them know in advance that time limits will be strict. Cut them off if they overrun.
One great approach if you have a v big event is to get them to create a 1-min video each, to be watched separately by judges.
(I’ve learnt a lot more since I originally wrote this (for instance, how to debug your tests), so this is an updated version).
This weekend I was part of a team that took part in the annual Hack Manchester hackathon (and we won Best in Show! Yay!). We used .Net Core for our back end code, and we got stuck in the middle of the night trying to add tests to our solution. It turned out the solution was pretty simple, so I’m documenting it here.
There are two versions below. The one you choose will probably depend on things like deployment pipelines. If you are doing anything other than a quick hack, Version 1 is probably better.
To be perfectly honest, the only reason I moved from one to another was because I (mistakenly) thought I couldn’t debug the tests or run them in an IDE unless they were in a separate project. It turned out that the only thing preventing me was that I hadn’t installed the relevant extension (see “Debug the tests / run the tests from an IDE” below).
Place tests in a separate project/folder
Keep all the tests in same folder/project as the source. This is quicker / simpler.
Version 1 – keep tests in separate folder/project
This version places tests in a separate project / folder. This is probably better if you want a deployment pipeline.
NB If your source is currently in your root folder, then you’ll need to move it into a separate folder (eg a src folder). This is easy:
Close down any IDEs you have running
Create a new src folder
If you don’t have a *.sln file, create one by opening the project in Visual Studio or running the command: dotnet new sln
Edit your solution file so that your csproj is prefixed by its new folder name
For me that meant changing ” TimeTravelApi.csproj” to “src/TimeTravelApi.csproj”
Move everything except *.sln into your new src folder
Create a separate tests folder in your root folder
Navigate to your new tests folder
Create the nunit project:
There are two ways of doing this.
The first way is to run this command: dotnet new “NUnit 3 Test Project”
The second way is to manually add three new packages: NUnit, Microsoft.NET.Test.Sdk and NUnit3TestAdapter – see below for how to do this manually.
Add a reference to your source project:
Run this command (replace “YourProject” with your project name): dotnet add reference ../src/YourProject.csproj
If you get an error about “incompatible targeted frameworks” then:
Go into your tests.csproj and change the .Net version from 2.0 to 2.1 like this: <TargetFramework>netcoreapp2.1</TargetFramework>
Run this command to upgrade the nunit version: dotnet add package nunit -v 3.11.0
! This works in Oct 2018, but it might be different in the future!
Add your new tests project to the solution:
Navigate back up to your root folder
Command: dotnet sln add ./tests/tests.csproj
Write and run some tests (see “Write and run some tests” below)
Version 2 – keep tests in same folder/project as source
This version keeps all the tests in same folder/project as the source. This is quicker / simpler if you are trying to keep things small and simple.
Add the necessary packages:
You can run the separate package commands on the command line (see below), but you’re probably better off using the dedicated nunit command.
Dedicated nunit command:
Command line: dotnet new “NUnit 3 Test Project”
Separate commands for each package (check versions – this was written Oct 2018):