Creating Hyperskill problems

About Hyperskill problems

On Hyperskill, testing with the hs-test library is used when testing stages of projects. However, it is possible to use this library to write standalone problems for various topics in the knowledge map. The specifics of creating such problems will be described below.

We'll continue from the end of the JVM languages initial setup page.
If you want to create a problem for a non-JVM language, you can start from non-JVM languages initial setup page.

Differences from projects

There are several key differences between projects on Hyperskill and problems on Hyperskill using the hs-test library:

1. In the projects the initial template is only present in the first stage, while in the problems the initial template is present in every stage. This is because in projects, the user's solution moves from stage to stage, whereas problems can be solved by the user in any order and are actually independent of each other.
2. In projects, only tests are hidden and all solution files must be visible to the user. In problems, part of the solution can be hidden and the user will only see a visible part of the solution to make changes in it. For a problem that can be solved in the Hyperskill web interface, it must have only one visible file (but it may contain more than one visible file, in this case it can be solved only in IDE).

You can create several problems in within a EduTools project.

Requirements

If you want your solution to be solvable in the web-interface, there are some requirements you have to follow:

1. Tests and solution should not connect to the internet since they are run inside an isolated environment. However, you can host the server on localhost and solution can connect to it.

2. Tests and solution should not use additional libraries not included in the standard library. You can ask Hyperskill team for including some libraries to be installed inside an isolated environment.

   1. If tests are written in Java or Kotlin, you can use GSON library since hs-test uses it also.
   2. If you are writing a Spring Boot problem, you can use the following dependencies in your problem.

Example

Spring Boot problem, that can be solved both in the web interface and in the IDE. Don't be confused with Tests.java with gradle logo being shown in the root of the stage - it's actually build.gradle file on the disk, it's UI bug in EduTools plugin - EDU-4801. You can see that the first problem has only one visible file named src/task/SimpleController.java (it has black text color), while others are hidden (they have gray text color). You can find out how to set some files visible/invisible in the initial setup page.

Key observations:

1. Try to leave only 1 visible file, so that users will be able to solve the problem in the web interface.
2. Try to leave all the necessary imports in place so that users won't struggle with them since they don't have code completion when they try to solve the problem in the web interface. But at the same time, don't hint the exact solution by showing exact imports. For example, in Java you can use star imports so that the user wouldn't be spoiled the solution and at the same time wouldn't have to type imports.
3. You don't have to edit task.html in EduTools, it's better to edit it on Stepik. But be aware that you shouldn't edit problem description on Stepik while you edit tests in EduTools - you will end up erasing either description on Stepik or tests in EduTools. After you made some edits on Stepik, you need to redownload the lesson in EduTools or copy HTML description in Stepik and paste it to task.html in the same step in IDE.

If you want to write tests for the Spring Boot problem, use regular Testing Spring Boot instruction and Checking JSON instructions.