\n', base64enc::base64encode(pngf)))
52 | ```
53 |
54 | ## Services
55 |
56 | None
57 |
58 | ## Language ID
59 |
60 | `r`
61 |
--------------------------------------------------------------------------------
/__tmp__/wiki/tutorial-approving-translations.md:
--------------------------------------------------------------------------------
1 | Sometimes, a user will create a translation of your kata. Most users notify you with a comment. So where can you find those translations? Let's have a look at the language dropdown:
2 |
3 | 
4 |
5 | Notice the little `+ Add New` at the bottom? Click on it to see the current list of translations:
6 |
7 | 
8 |
9 | Here you get a quick overview of all translations. To see them in detail and approve, decline or fork them, click on the translation's title, in this case, "Reverse every other word in the string" PHP translation.
10 |
11 | Now, in order to *approve* or *decline* the translation, a click on the correct buttons (top on the right-hand side) is sufficient.
12 |
13 | 
14 |
15 | ## Remarks on accepting a translation
16 |
17 | Before you accept a translation, make sure that the difficulty and quality of the translation matches the current languages. In doubt, write a comment on the translation. If the translation diverges from the original kata, ask the translator politely whether (s)he can modify the translation so that it matches your intent.
18 |
19 | If you want to comment on the translation, you can do that on the "Discourse" page, just as in normal katas or Kumites. This is especially helpful if you're not sure whether the translation really reflects your original intentions.
20 |
21 | *(Note: this tutorial is a stub. Please expand it)*
--------------------------------------------------------------------------------
/content/concepts/kata/satisfaction-rating.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Satisfaction Rating
3 | tags: [concept]
4 | ---
5 |
6 |
7 | _TBD: this page was imported from old CW wiki and needs to be reviewied/redacted._
8 |
9 | The satisfaction rating is the score shown here:
10 |
11 | 
12 |
13 | It indicates the number of satisfied users. This score is derived from the votes shown after you complete a kata. You can either vote very, somewhat or not satisfied, as shown here:
14 |
15 | 
16 |
17 | ## How should I interpret these votes?
18 |
19 | - If you got a lot of value out of the kata and found it to be well constructed, you should vote "Very"
20 | - If you got some value out of the kata but the quality may not be top notch, you should vote "Somewhat"
21 | - If you got no value out of the kata, in regards to enjoyment, education experience, etc, then you should pick "None".
22 |
23 | #### A special note about the "None" vote
24 |
25 | If you think the kata itself is valuable but you simply have some issues with it, then you should select "Somewhat" and create an issue instead. If you thought the kata is really great, other than the issues, then you can choose "Very". Please do not choose "None" simply because the kata has an issue but it is otherwise a good kata. The satisfaction rating is meant to indicate quality of kata as a concept, not its current state of condition in terms of open issues.
26 |
--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "@codewars/docs",
3 | "version": "0.1.0",
4 | "private": true,
5 | "scripts": {
6 | "format": "prettier --write .",
7 | "lint:format": "prettier --check .",
8 | "docusaurus": "docusaurus",
9 | "start": "docusaurus start",
10 | "build": "docusaurus build",
11 | "swizzle": "docusaurus swizzle",
12 | "deploy": "docusaurus deploy",
13 | "clear": "docusaurus clear",
14 | "serve": "docusaurus serve",
15 | "write-translations": "docusaurus write-translations",
16 | "write-heading-ids": "docusaurus write-heading-ids"
17 | },
18 | "dependencies": {
19 | "@docusaurus/core": "^2.0.0-beta.21",
20 | "@docusaurus/preset-classic": "^2.0.0-beta.21",
21 | "@mdx-js/react": "^1.6.21",
22 | "@tabler/icons": "^1.40.2",
23 | "clsx": "^1.1.1",
24 | "copy-text-to-clipboard": "^3.0.1",
25 | "react": "^17.0.1",
26 | "react-dom": "^17.0.1"
27 | },
28 | "browserslist": {
29 | "production": [
30 | ">0.5%",
31 | "not dead",
32 | "not op_mini all"
33 | ],
34 | "development": [
35 | "last 1 chrome version",
36 | "last 1 firefox version",
37 | "last 1 safari version"
38 | ]
39 | },
40 | "devDependencies": {
41 | "autoprefixer": "^10.2.5",
42 | "netlify-plugin-cache": "^1.0.3",
43 | "postcss": "^8.2.13",
44 | "postcss-nested": "^5.0.5",
45 | "postcss-preset-env": "^6.7.0",
46 | "prettier": "^2.2.1",
47 | "shiki": "^0.10.1",
48 | "tailwindcss": "^2.2.2",
49 | "unist-util-visit": "^2.0.3"
50 | }
51 | }
52 |
--------------------------------------------------------------------------------
/content/languages/julia/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Julia
3 | description: Julia on Codewars
4 | slug: /languages/julia
5 | tags: [julia]
6 | ---
7 |
8 |
9 | ## Status
10 |
11 | Beta
12 |
13 | ## Versions
14 |
15 | - 1.0
16 | - 1.5
17 |
18 | ## Test Frameworks
19 |
20 | [FactCheck](https://github.com/codewars/FactCheck.jl)
21 |
22 | ### Minimum Example
23 | ```julia
24 | module Adder
25 | export add
26 | function add(a, b)
27 | a + b
28 | end
29 | end
30 | ```
31 | ```julia
32 | using FactCheck
33 | facts("add") do
34 | @fact Adder.add(1, 1) --> 2
35 | end
36 | ```
37 |
38 | ### With Random Tests
39 | ```julia
40 | using FactCheck
41 | using .Solution
42 |
43 | facts("multiply") do
44 | context("fixed tests") do
45 | @fact multiply(2, 2) --> 4
46 | @fact multiply(1, 1) --> 1
47 | @fact multiply(3, 2) --> 6
48 | end
49 |
50 | context("random tests") do
51 | for _ = 1:100
52 | a = rand(-100:100)
53 | b = rand(-100:100)
54 | # Note that the string after the assertions is for custom error message,
55 | # but used as test case name on Codewars.
56 | @fact multiply(a, b) --> a*b "multiply($(a), $(b))"
57 | end
58 | end
59 | end
60 | ```
61 |
62 | ## Timeout
63 | 12 seconds
64 |
65 | ## Packages
66 | ### 1.5
67 | ```toml
68 | [deps]
69 | DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8" # version = "0.18.9"
70 | IterTools = "c8e1da08-722c-5040-9ed9-7db0dc04731e" # version = "1.3.0"
71 | Lazy = "50d2b5c4-7a5e-59d5-8109-a42b560f39c0" # version = "0.15.1"
72 | ```
73 |
74 | ## Services
75 | None
76 |
77 | ## Language ID
78 |
79 | `julia`
80 |
--------------------------------------------------------------------------------
/content/authoring/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Authoring Content
3 | slug: /authoring
4 | tags: [authoring]
5 | ---
6 |
7 | All content available on Codewars is created by members of the Codewars community. It's ideas of Codewars users that get turned into kata, and the fact that users are familiar with plenty of programming languages allows for a large number of available translations.
8 |
9 | This section of the documentation is meant mostly for authors and translators who would like to introduce new challenges and make them available for other Codewars users. Creating a kata or translating it, even an easy one, is a difficult task. It requires a much wider set of skills compared to that of just solving a kata. Unlike problem solvers, authors need to master skills related to software development in general, as well as problem design, writing good test suites, documenting the task and its requirements, and communicating with reviewers.
10 |
11 | To support users in creating good quality kata and translations, a set of help pages were created with articles related to content authoring activities: tutorials explaining how to create and translate a kata, and a reference of [guidelines][authoring-guidelines] and requirements that every author should follow to make sure that a piece of content created by them meets quality criteria.
12 |
13 | For more details, see help pages related to creating a specific type of content:
14 | - [Creating a kata][authoring-kata]
15 | - [Creating a translation][authoring-translation]
16 |
17 | [authoring-guidelines]: /authoring/guidelines/
18 | [authoring-kata]: /authoring/kata/
19 | [authoring-translation]: /authoring/translation/
20 |
--------------------------------------------------------------------------------
/content/languages/java/junit.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: JUnit
3 | tags: [java, reference, testing]
4 | ---
5 |
6 | You can use JUnit [4](https://junit.org/junit4/) or [5](https://junit.org/junit5/) in Codewars. 5 offers nesting, pretty name display and multiple test classes.
7 |
8 | Note that JUnit assertions use `(expected, actual)` parameter ordering rather than the typical `(actual, expected)`.
9 |
10 | ## Basic Setup
11 |
12 | ### Example solution
13 |
14 | ```java
15 | public class Adder {
16 | public static int add(int a, int b) {
17 | return a + b;
18 | }
19 | }
20 | ```
21 |
22 | ### JUnit 4
23 |
24 | ```java
25 | import org.junit.Test;
26 | import static org.junit.Assert.assertEquals;
27 |
28 | public class AdderTests {
29 | @Test
30 | public void testAdd() {
31 | assertEquals(3, Adder.add(1, 2));
32 | }
33 | }
34 | ```
35 |
36 | ### JUnit 5
37 |
38 | ```java
39 | import org.junit.jupiter.api.DisplayName;
40 | import org.junit.jupiter.api.Nested;
41 | import org.junit.jupiter.api.Test;
42 | import static org.junit.jupiter.api.Assertions.assertEquals;
43 |
44 | @DisplayName("Testing Adder")
45 | class AdderTests {
46 | @Test
47 | @DisplayName("Adder.add(1, 1) returns 2")
48 | void testPositives() {
49 | assertEquals(2, Adder.add(1, 1), "1 + 1 should equal 2");
50 | }
51 |
52 | @Nested
53 | @DisplayName("Negative Integers")
54 | class NegativeTests {
55 | @Test
56 | @DisplayName("Adder.add(-1, -1) returns -2")
57 | void testNegatives() {
58 | assertEquals(-2, Adder.add(-1, -1), "-1 + -1 should equal -2");
59 | }
60 | }
61 | }
62 | ```
63 |
--------------------------------------------------------------------------------
/__tmp__/popups/tips-advanced-code-fencing.md:
--------------------------------------------------------------------------------
1 | ---
2 | subject: "Tips: Advanced Code Fencing"
3 | on:
4 | paths:
5 | - /translation/new
6 | ---
7 |
8 | The description for a translation is shared between all languages for a kata. There are some enhanced markdown options available to allow you to selectively show content based off of the language - including a recently introduced ability to use `if` and `if-not` statements.
9 |
10 | ## Basic Code Block Filtering:
11 |
12 | The easiest way to provide language specific content is when providing language specific code examples. If you simply place language examples on top of each other, only the one related to the current language will be shown.
13 |
14 | ````
15 | ```javascript
16 | function example(){
17 | // only shown if javascript is active
18 | }
19 | ```
20 | ```ruby
21 | def example
22 | # only shown if ruby is active
23 | end
24 | ```
25 | ````
26 |
27 | ## Filterable Markdown Blocks
28 |
29 | A newer feature on Codewars is the ability to filter entire sections of markdown using `if` and `if-not` statements. These statements are also used with code blocks. The following examples try to illustrate different ways in which you can use these statements.
30 |
31 | ````
32 | ~~~if:javascript,ruby
33 | This content will only be shown if javascript or ruby are active.
34 |
35 | > A few things to note:
36 | - Markdown is still available to be used within these code blocks
37 | ~~~
38 | ~~~if-not:ruby
39 | This markdown will only be shown if ruby **is not** the active language.
40 | ```javascript
41 | // still only shown if javascript is the active language, since it has multiple examples next to it
42 | ```
43 | ```python
44 | # only shown if python is active
45 | ```
46 | ~~~
47 | ````
48 |
--------------------------------------------------------------------------------
/content/community/moderation/tools.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Community Moderation Tools
3 | sidebar_label: Moderation Tools
4 | tags: [reference]
5 | slug: /community/moderation/tools
6 | ---
7 |
8 | [Moderators](/community/moderation/#moderators) are a group of users selected to support other users with handling problems related to content and the community. They have access to tools and features not available to regular users, which can be used to solve problems reported by community members. In particular, moderators can:
9 |
10 | - Handle problematic users, cheaters, and griefers:
11 | - Handle reports about dishonest users
12 | - Flag solutions as cheat
13 | - Revoke privileges related to authoring
14 | - Remove dubious votes on beta kata
15 | - Manually fix effects of some bugs:
16 | - Revalidate solutions which do not pass tests anymore but haven't been invalidated automatically
17 | - Force recalculation of broken satisfaction rating on beta kata
18 | - Force solutions affected by the grouping bug to appear on the kata solutions page
19 | - Ensure quality of content:
20 | - Unpublish unapprovable or severely broken beta kata
21 | - Hide solutions which can be considered spoilers from kata solutions page (for example a highly optimized solution to an easy version of a 7 kyu kata which can be used to solve 2 kyu, challenge version)
22 | - Approve changes to documentation
23 | - Manage Codewars repositories, boards, and chats:
24 | - [codewars/codewars.com](https://github.com/codewars/codewars.com) GitHub repository
25 | - [codewars/docs](https://github.com/codewars/docs) GitHub repository
26 | - [codewars/content-issues](https://github.com/codewars/content-issues) GitHub repository
27 | - [Codewars Discord server](https://discord.gg/7U9t33jrgG)
28 |
--------------------------------------------------------------------------------
/content/languages/elm/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Elm
3 | description: Elm on Codewars
4 | slug: /languages/elm
5 | tags: [elm]
6 | ---
7 |
8 |
9 | ## Versions
10 |
11 | 0.19
12 |
13 | ## Test Frameworks
14 |
15 | [elm test](https://github.com/elm-explorations/test)
16 |
17 | ### Example
18 |
19 | The name of the solution module can be anything.
20 | Extra module can be provided in preloaded section.
21 |
22 | ```elm
23 | module Example exposing (..)
24 |
25 | add : Int -> Int -> Int
26 | add x y = x + y
27 | ```
28 |
29 | ```elm
30 | module ExampleTest exposing (..)
31 |
32 | import Expect exposing (Expectation)
33 | import Test exposing (..)
34 |
35 | import Example
36 |
37 | suite : Test
38 | suite =
39 | describe "Example"
40 | [ test "add" <|
41 | \_ ->
42 | Example.add 1 1
43 | |> Expect.equal 2
44 | ]
45 | ```
46 |
47 | `Fuzz` can be used for property based testing:
48 |
49 | ```elm
50 | module ExampleTest exposing (..)
51 |
52 | import Expect exposing (Expectation)
53 | import Test exposing (..)
54 | import Fuzz
55 |
56 | import Example
57 |
58 | suite : Test
59 | suite =
60 | describe "Example"
61 | [ fuzz2 Fuzz.int Fuzz.int "add" <|
62 | \a b ->
63 | Example.add a b
64 | |> Expect.equal (a + b)
65 | ]
66 | ```
67 |
68 | ## Timeout
69 |
70 | 12 seconds
71 |
72 | ## Packages
73 |
74 | - `elm/core`
75 | - `elm-community/array-extra`
76 | - `elm-community/basics-extra`
77 | - `elm-community/dict-extra`
78 | - `elm-community/list-extra`
79 | - `elm-community/maybe-extra`
80 | - `elm-community/random-extra`
81 | - `elm-community/string-extra`
82 | - `elm-explorations/test`
83 |
84 | ## Services
85 |
86 | None
87 |
88 | ## Language ID
89 |
90 | `elm`
91 |
--------------------------------------------------------------------------------
/content/languages/riscv/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: RISC-V
3 | sidebar_label: Overview
4 | slug: /languages/riscv
5 | ---
6 |
7 | ## Status
8 |
9 | Beta
10 |
11 | ## Version
12 |
13 | QEMU Toolchain: QEMU 7.1, GCC 11.3.0, Binutils 2.38
14 |
15 | ISA String: RV64GCV_Zba_Zbb_Zbc_Zbs_Zbkx_Zk_Zks
16 |
17 | Codewars uses [QEMU user mode emulation](https://www.qemu.org/docs/master/user/main.html) to support RISC-V content. Codewars is configured to use the following extensions for RISC-V:
18 | - `G` - General-Purpose*
19 | - `C` - Compressed*
20 | - `V` - Vector*†
21 | - Zb* - Bit-Manipulation‡
22 | - `Zba` - Address Generation
23 | - `Zbb` - Basic
24 | - `Zbc` - Carry-less
25 | - `Zbs` - Single-bit
26 | - Cryptography - Scalar§
27 | - `Zbkx` - Crossbar permutation
28 | - `Zk` - Standard
29 | - `Zks` - ShangMi
30 |
31 | The most recent version of the specification for each can be downloaded below (as of 26 Dec 2023):
32 | - *RISC-V Unprivileged Specification
33 | - †Vector Extension Specification
34 | - ‡Bit-Manipulation Extension Specification
35 | - §Cryptography Extension Specification
36 |
37 | ## Test Frameworks
38 |
39 | [Cgreen](https://cgreen-devs.github.io/cgreen/)
40 |
41 | ## Timeout
42 |
43 | 12 seconds
44 |
45 | ## Packages
46 |
47 | Cgreen test framework (`libcgreen`)
48 |
49 | ## Services
50 |
51 | None
52 |
53 | ## Language ID
54 |
55 | `riscv`
56 |
--------------------------------------------------------------------------------
/content/getting-started/registering.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Sign up to Codewars
3 | ---
4 |
5 | You’ve decided to join Codewars; that’s great! If you need help signing up, follow these steps to create your new account and start solving tasks (Kata), learning, and improving your programming skills!
6 |
7 | ## How to sign up
8 | First, go to our [sign-up](https://www.codewars.com/join) page. Here, you will have the option to create a Codewars account in one of two ways;
9 | 1. Type your username and email address, and create a password.
10 | 2. Sign up using your GitHub Account.
11 |
12 | **Important note:**
13 | Once your account is set up, you will receive an email asking to confirm your email address. Please be aware that certain features on Codewars will be limited until your account is confirmed. Check your spam folder if you cannot find the email in your inbox.
14 |
15 | If you can’t find this email, you can request it again by logging into your account, heading to your ‘account settings,’ and selecting ‘resend.’
16 |
17 | ## Establish your training settings
18 | Once you have signed up, you can select some training settings on Codewars. These settings will help us recommend challenges (Kata) to you and provide you with more opportunities on Codewars. These settings allow you to tell us how much programming experience you have, what languages you have experience in, and what programming languages you wish to train in (e.g., what languages you will challenge yourself with Codewars Kata).
19 |
20 | ## What’s next?
21 | Once your training settings have been saved, you will be brought to your training dashboard. Here, you will find your allies (accounts you follow or members of your [Clan](https://docs.codewars.com/community/following/#clans)), the latest comments on Codewars, and, most importantly, your [next challenge to solve](https://docs.codewars.com/getting-started/finding-kata/).
22 |
23 | You’re now ready to train on Codewars; enjoy!
24 |
--------------------------------------------------------------------------------
/content/authoring/translation.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Translating a Kata
3 | tags: [authoring]
4 | ---
5 |
6 | _TBD: improve this stub_
7 |
8 | New translators may refer to the [tutorial(TODO)](/authoring/translation/).
9 |
10 | Some [languages](/languages/) also have a page dedicated to authoring kata, with code examples and best practices.
11 |
12 | Every translator should follow [translation authoring guidelines](/authoring/guidelines/translation/).
13 |
14 | After being published, every translation goes through a series of [reviews](/curation/translation/) before it can be approved.
15 |
16 |
33 |
34 | [sequential-code-blocks]: /references/markdown/extensions/#sequential-code-blocks
35 | [conditional-rendering]: /references/markdown/extensions/#conditional-rendering
36 |
--------------------------------------------------------------------------------
/content/getting-started/kata-solved.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: After Solving a Kata
3 | ---
4 |
5 | Finally, this great moment happened: the test output panel is all green, and you were able to submit your solution. Congratulations! It's time to collect your reward. It's also a good time to share some feedback, to guide others who'd encounter the same kata.
6 |
7 | ## Rewards
8 |
9 | You worked hard to solve your last challenge, and after you succeeded, you definitely deserve a reward. Each solved tasks rewards you in two ways: progressing your rank, and granting some amount of Honor points. The more difficult kata you solve, the bigger the reward.
10 |
11 | ### Rank
12 |
13 | The rank level reflects your experience and knowledge you have gained by solving kata. You start at the lowest rank of 8 kyū, and each correct solution brings you closer to a higher rank. You can see your rank progress toward the next level on your profile page:
14 |
15 | 
16 | 
17 |
18 | More information on ranks and progress can be found [here](/gamification/ranks/).
19 |
20 | ### Honor
21 |
22 | Honor points are rewarded by contributing to Codewars in many ways, and solving a kata is one of them. By earning Honor points, you gain additional [privileges](/gamification/privileges/) and climb [leaderboards](gamification/honor#leaderboards-and-honor-percentile).
23 |
24 | ## Feedback
25 |
26 | After you have successfully solved a task, you can let others know how you liked it. One way to do this is to leave your satisfaction vote:
27 |
28 | 
29 | 
30 |
31 | You can also participate in the discussion on a kata. If you wish to log an issue about this specific kata, such as poorly worded descriptions or issues with test cases, then you can leave a comment in the discourse section. More on this in the next part.
32 |
--------------------------------------------------------------------------------
/content/languages/powershell/pester.md:
--------------------------------------------------------------------------------
1 | ---
2 | tags:
3 | - powershell
4 | - reference
5 | - testing
6 | ---
7 |
8 | # Pester
9 |
10 | ## Basic Setup
11 |
12 | ### Solution
13 |
14 | ```powershell
15 | function Add-Numbers($a, $b) {
16 | return $a + $b
17 | }
18 | ```
19 |
20 | ### Tests
21 |
22 | ```powershell
23 | BeforeAll {
24 | . $PSCommandPath.Replace(".Tests.ps1", ".ps1")
25 | }
26 |
27 | Describe "Add-Numbers" {
28 | It "adds positive numbers" {
29 | Add-Numbers 1 1 | Should -Be 2
30 | }
31 | It "adds negative numbers" {
32 | Add-Numbers 1 -6 | Should -Be -5
33 | }
34 | }
35 | ```
36 |
37 | ## Improving Logging
38 |
39 | Because Pester doesn't provide a way to log extra information (and outputting from the solution interferes with the actual returned value), debugging on Codewars can be difficult. `Write-Host` somewhat works by bypassing Pester. But all of the logs will be shown at the top and not inside each test cases like many of the other languages.
40 |
41 | Tests like the following can help minimize the frustration:
42 |
43 | ```powershell
44 | Describe "Multiply" {
45 | Context "Fixed Tests" {
46 | # Parameterized test
47 | It "Multiply is " -TestCases @( 48 | @{ a = 2; b = 2; p = 4 } 49 | @{ a = 1; b = 1; p = 1 } 50 | @{ a = 2; b = 3; p = 6 } 51 | @{ a = 3; b = 2; p = 6 } 52 | ) { 53 | param ($a, $b, $p) 54 | Multiply $a $b | Should Be $p 55 | } 56 | } 57 | Context "Random Tests" { 58 | # try to generate useful test case names because 59 | # inspecting the arguments is difficult 60 | $rand = New-Object System.Random 61 | For ($i=0; $i -lt 100; $i++) { 62 | $a = $rand.next(1, 100) 63 | $b = $rand.next(1, 100) 64 | $p = $a * $b 65 | It("Multiply $($a) $($b) is $($p)") { 66 | Multiply $a $b | Should Be $p 67 | } 68 | } 69 | } 70 | } 71 | ``` 72 | 73 | 78 | -------------------------------------------------------------------------------- /content/languages/ruby/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Ruby 3 | description: Ruby on Codewars 4 | slug: /languages/ruby 5 | tags: [ruby] 6 | --- 7 | 8 | 9 | ## Versions 10 | 11 | - 2.5 12 | - 3.0 13 | 14 | ## Test Frameworks 15 | 16 | From Ruby 3.0, [RSpec](https://rspec.info/) is used under the hood: 17 | 18 | ```ruby 19 | # Defaults to the global `describe` for backwards compatibility, but `RSpec.desribe` works as well. 20 | describe "Example" do 21 | it "should return the sum" do 22 | expect(add(1, 1)).to eq(2), "failure message" 23 | # The following is still supported, but new tests should not use them. 24 | # Test.assert_equals(add(1, 1), 2, "failure message") 25 | end 26 | end 27 | ``` 28 | 29 | Note that if an assertion message is provided while using RSpec, actual and expected results have to be in that message otherwise the information will not be shown to the user. 30 | See [`rspec-expectations`](https://rspec.info/documentation/3.10/rspec-expectations/). 31 | 32 | Earlier versions use [Codewars Test Framework](https://github.com/Codewars/codewars.com/wiki/Codewars-Ruby-Test-Framework) with similar syntax. 33 | 34 | ## Timeout 35 | 36 | 12 seconds 37 | 38 | ## Packages 39 | 40 | 41 | 42 | ### Ruby MRI 2.5 43 | 44 | - activesupport (5.2.0) 45 | - factory_bot (4.8.2) 46 | - faker (1.8.7) 47 | - faraday (0.15.1) 48 | - mongo (2.5.3) 49 | - mongoid (6.2.0) 50 | - nokogiri (1.8.2) 51 | - pg (1.0.0) 52 | - rack (2.0.5) 53 | - rails (5.2.0) 54 | - redis (4.0.1) 55 | - rspec (3.7.0) 56 | - rspec-its (1.2.0) 57 | - sequel (5.8.0) 58 | - sinatra (2.0.1) 59 | - sqlite3 (1.3.13) 60 | - webmock (3.4.2) 61 | 62 | ### Ruby MRI 3.0.0 63 | 64 | - faker (2.17.0) 65 | - faraday (1.3.0) 66 | - mongo (2.14.0) 67 | - nokogiri (1.11.2) 68 | - pg (1.2.3) 69 | - rack (2.2.3) 70 | - rack-test (1.1.0) 71 | - redis (4.2.5) 72 | - rspec (3.10.0) 73 | - sequel (5.42.0) 74 | - sinatra (2.1.0) 75 | - sqlite3 (1.4.2) 76 | - webmock (3.12.2) 77 | 78 | ## Services 79 | 80 | - sqlite 81 | - redis 82 | - mongodb 83 | 84 | ## Language ID 85 | 86 | `ruby` 87 | -------------------------------------------------------------------------------- /content/concepts/kata/solutions.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Solutions 3 | tags: [concept] 4 | --- 5 | 6 | Each time a warrior completes a kata within a given language, their solution is added to the list of successful solutions for that particular language. After completing a kata you are immediately taken to this page, often giving you an Aha! moment when you realize how others have completed the same task. This moment can be incredibly enlightening if you come across solutions that had a different approach than yours. 7 | 8 | ## Who can see solutions? 9 | 10 | Code Warriors are able to view the solutions to a kata under one of the following two conditions: 11 | 12 | 1. They have completed the kata: Once you have completed all of the tests and submitted your final version, you will be taken to the solutions page. 13 | 2. They have forfeited their honor: If you choose to give up on the kata, you can click the `Unlock Solutions` button within the kata trainer. This will forfeit any honor and rank progression that you could earn on the kata. You will then be taken to the solutions page. 14 | 15 | ## Solution Groupings 16 | 17 | A basic algorithm is used to try to match new solutions to existing ones, so that the list does not become littered with duplicate solutions. Basic syntax structures, comments, and in some cases, alias method names, will be removed so that solutions can be compared. 18 | 19 | When two or more solutions are grouped, then the first submitted one is used as a representative solution from this group and presented on the `Solutions` page. 20 | 21 | ## Solution page 22 | 23 | TBD 24 | 25 | ## Voting 26 | 27 | TBD 28 | 29 | ## Comments 30 | 31 | TBD 32 | 33 | ## Forking solutions 34 | 35 | TBD 36 | 37 | ## Invalid solutions (?) 38 | 39 | TBD 40 | 41 | - Penalty for invalidation 42 | - Automatic invalidation 43 | - Manual verification (?) 44 | 45 | ## Where to see solutions 46 | 47 | TBD 48 | 49 | - `Solutions` tab on kata 50 | - Solution page 51 | - Discourse `View solution` collapsible 52 | - `Solutions` tab in profile (`Refactor` button) 53 | - `Past solutions` tab in trainer 54 | -------------------------------------------------------------------------------- /__tmp__/popups/tips-kata-translations.md: -------------------------------------------------------------------------------- 1 | --- 2 | subject: "Tips: Kata Translations" 3 | on: 4 | paths: 5 | - /translation/new 6 | --- 7 | 8 | Kata translations are a great way of gaining honor, plus you are contributing to the overall community! A few things to remember: 9 | 10 | ### Description - Language Examples 11 | 12 | You may need to edit the description to provide info for the new language you are translating. This description field is **shared across all languages**. 13 | 14 | If the kata has language examples within the description, **DO NOT REPLACE THESE**. Instead you should add examples for the language you are translating directly underneath the other examples. When taking the kata, the other languages will be filtered out automatically. 15 | 16 | **Do not forget to add language examples!**. This is important. Your translation cannot be approved without them. If the kata description is so generic that no specific language examples are included, then you do not need to add any. 17 | 18 | ### Example Test Cases 19 | 20 | Please try to include example test cases, even if they were not included in some of the existing languages. For some rare kata they may not make sense but usually other Codewarriors will appreciate the kata much more if there are example test cases provided for them. 21 | 22 | ### Translations must be approved 23 | 24 | Once you publish your translation either a moderator or the kata author will approve it. A notification will be sent out, but sometimes translators like to leave a comment on the kata as well just so everyone knows. 25 | 26 | ## Description Tips: 27 | 28 | In the kata description you will sometimes need to provide language specific examples. You can use three backticks (fences) to do so. i.e: 29 | 30 | ```` 31 | ```javascript 32 | function example(){ 33 | } 34 | ``` 35 | ```` 36 | 37 | If the kata already has languages examples, do not delete them. Instead append your language example to the bottom of the existing ones, like so: 38 | 39 | ```` 40 | ```javascript 41 | function example(){ 42 | } 43 | ``` 44 | ```ruby 45 | def example 46 | end 47 | ``` 48 | ```` 49 | -------------------------------------------------------------------------------- /content/concepts/kumite.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: What is Kumite? 3 | tags: [concept] 4 | --- 5 | 6 | :::note 7 | This page was imported from old Codewars wiki and needs to be reviewied/redacted. 8 | ::: 9 | 10 | In karate, kumite (ko͞omiˌtā) is the practice of taking techniques learned from kata and applying them through the act of freestyle sparring. Continuing with the coding dojo theme, and the already well established concept of a code kata, we wanted to play with the idea of what a code kumite might look like within the Codewars community. It is a social experiment to see how developers could share ideas and then respond to them with code instead of just words. 11 | 12 | ## How does it work? 13 | 14 | Creating a new kumite will involve creating some code, with an optional description and set of test cases that prove it works. Once published, the code provided will be considered the first "move". You and any other user are then able to respond to that move with your own. You do this by "forking" the original move. Your fork can refactor the original code, add features, fix bugs, add additional tests, etc. Any fork can then also be forked, creating a series of moves that happen between 1 or more participants. 15 | 16 | ## What do I use this for? 17 | 18 | Lots of things really. You could show off something you learned, only to have others show you an even more efficient way of doing the same thing. Maybe you have discovered an interesting and experimental design pattern in your favorite language and want to show it off, where others could then expand on the idea. You could use it for teaching - Kata are great for well-defined problems, but when a solution is open to many interpretations you could allow your students to experiment with how they would approach it in their own way. 19 | 20 | One popular use-case for kumite is to use it as a starting point for fleshing out a new kata. You can convert your kumite to a kata. When you convert it, the kumite will no longer be published or searchable. 21 | 22 | We look forward to seeing what the Codewars community comes up with! How would you utilize this format for something interesting? 23 | -------------------------------------------------------------------------------- /tailwind.config.js: -------------------------------------------------------------------------------- 1 | const colors = require("tailwindcss/colors"); 2 | const plugin = require("tailwindcss/plugin"); 3 | 4 | module.exports = { 5 | mode: "jit", 6 | purge: [ 7 | "./src/**/*.{js,jsx,ts,tsx}", 8 | // Don't look in `content/` for now because this can generate unnecessary classes and also cause issues. 9 | // For example, Prism adds `table` class to a token in TOML, and because some pages uses the word `table`, 10 | // `.table` is generated, and that token gets `display: table`. 11 | // "./content/**/*.mdx", 12 | ], 13 | corePlugins: { 14 | preflight: false, 15 | }, 16 | // Using custom dark variant `html[data-theme="dark"]` to match Docusaurus. 17 | darkMode: false, 18 | theme: { 19 | extend: { 20 | colors: { 21 | brand: "#b1361e", 22 | amber: colors.amber, 23 | fuchsia: colors.fuchsia, 24 | pink: colors.pink, 25 | // Admonitions colors 26 | note: colors.coolGray[600], 27 | "note-content": colors.coolGray[600], 28 | "note-content-dark": colors.coolGray[400], 29 | tip: colors.emerald[700], 30 | "tip-content": colors.emerald[700], 31 | "tip-content-dark": colors.emerald[500], 32 | info: colors.sky[600], 33 | "info-content": colors.sky[700], 34 | "info-content-dark": colors.sky[500], 35 | warning: colors.orange[600], 36 | "warning-content": colors.orange[700], 37 | "warning-content-dark": colors.orange[500], 38 | caution: colors.red[500], 39 | "caution-content": colors.red[700], 40 | "caution-content-dark": colors.red[400], 41 | }, 42 | }, 43 | }, 44 | variants: { 45 | extend: { 46 | backgroundColor: ["dark"], 47 | textColor: ["dark"], 48 | display: ["dark"], 49 | }, 50 | }, 51 | plugins: [ 52 | plugin(({ addVariant, e }) => { 53 | addVariant("dark", ({ modifySelectors, separator }) => { 54 | modifySelectors(({ className }) => { 55 | return `html[data-theme="dark"] .${e( 56 | `dark${separator}${className}` 57 | )}`; 58 | }); 59 | }); 60 | }), 61 | ], 62 | }; 63 | -------------------------------------------------------------------------------- /__tmp__/popups/kumite.md: -------------------------------------------------------------------------------- 1 | --- 2 | subject: "Welcome to Kumite!" 3 | teaser: | 4 | Kumite is a long running experiment on Codewars to see what happens when Codewarriors "spar" with each other. 5 | on: 6 | paths: 7 | - /kumite$ 8 | --- 9 | 10 | ## What is Kumite? 11 | 12 | In karate, kumite (ko͞omiˌtā) is the practice of taking techniques learned from kata and applying them through the act of freestyle sparring. Continuing with the coding dojo theme, and the already well established concept of a code kata, we wanted to play the idea of what a code kumite would look like within the Codewars community. It is a social experiment to see how developers could share ideas and then respond to them with code instead of just words. 13 | 14 | ## How does it work? 15 | 16 | Creating a new kumite will involve creating some code, with an optional description and set of test cases that prove it works. Once published, the code provided will be considered the first "move". You and any other code warrior are then able to respond to that move with your own. You do this by "forking" the original move. Your fork can refactor the original code, add features, fix bugs, add additional tests, etc. Any fork can then also be forked, creating a series of moves that happen between 1 or more participants. 17 | 18 | ## What do I use this for? 19 | 20 | Lots of things really. You could show off something you learned, only to have others show you an even more efficient way of doing the same thing. Maybe you have discovered an interesting and experimental design pattern in your favorite language and want to show it off, where others could then expand on the idea. You could use it for teaching - Kata are great for well defined problems, but when a solution is open to many interpretations you could allow your students to experiment with how they would approach it in their own way. 21 | 22 | One popular use-case for kumite is to use it as a starting point for fleshing out a new kata. You can convert your kumite to a kata. When you convert it, the kumite will no longer be published or searchable. 23 | 24 | We look forward to seeing what the Codewars community comes up with! How would you utilize this format for something interesting? 25 | -------------------------------------------------------------------------------- /content/authoring/guidelines/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Content Authoring Guidelines 3 | tags: [authoring, reference] 4 | slug: /authoring/guidelines 5 | --- 6 | 7 | ## Overview 8 | 9 | This set of pages contains guidelines for kata authors and translators to help them create kata, translations, and kumite which adhere to the community's quality standards. 10 | 11 | The guidelines should be used by kata authors and translators to verify whether new content about to be introduced to Codewars is of sufficient quality. Conformity to these guidelines is a prerequisite for publishing a kata, translation, or kumite. 12 | 13 | Some of these guidelines do not apply to every type of content. There are code-golf kata, puzzle kata, hack-mes, debugging kata, and many other problems which are designed on the grounds of ignoring some of the guidelines. They should be used where applicable, and can be skipped when they are not. But this should not be treated as an excuse for taking shortcuts or skipping the necessary work: the fact that some of the guidelines are not relevant should be clearly visible from the task. 14 | 15 | :::warning Important note 16 | Failure to comply with the guidelines should be considered an issue to be addressed and reported. In case of severe violations, the affected kata or translation may be retired, moved back to beta, or rejected. 17 | 18 | Authors who repeatedly violate or ignore rules and introduce poor-quality content to the system can have their authoring privileges revoked and offending content withdrawn. 19 | ::: 20 | 21 | ## General Guidelines 22 | 23 | - **Conform to quality guidelines when creating new content.** Do not take shortcuts, don't be lazy. Know what are quality requirements for kata, translations, descriptions, and code. Do not push your responsibility to reviewers. 24 | - **Keep responsibility for all content you created.** You should actively maintain all content you introduced into Codewars: fix issues, consider suggestions, answer questions. Be aware that other users are allowed to improve your content. 25 | - Remember that you can always **ask others for help.** Whenever you need someone to proofread your description, answer any questions about how Codewars works, or just give any advice on the content you're working on. 26 | -------------------------------------------------------------------------------- /content/languages/purescript/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: PureScript 3 | description: PureScript on Codewars 4 | slug: /languages/purescript 5 | tags: [purescript] 6 | --- 7 | 8 | 9 | ## Status 10 | 11 | Beta 12 | 13 | ## Versions 14 | 15 | - [0.12.x](https://github.com/purescript/purescript/releases/tag/v0.12.2) 16 | - [0.15.x](https://github.com/codewars/purescript/releases/tag/0.15.4.2) 17 | 18 | ## Test Frameworks 19 | 20 | [spec](https://purescript-spec.github.io/purescript-spec) 21 | 22 | ### Example 23 | 24 | The name of the solution module can be arbitrary. Extra module can be provided in preloaded code. 25 | ```purescript 26 | module Example where 27 | 28 | import Prelude 29 | 30 | add' :: Int -> Int -> Int 31 | add' x y = x + y 32 | ``` 33 | 34 | The name of the test module **must** end with `Spec`. 35 | ```purescript 36 | module ExampleSpec where 37 | 38 | import Prelude 39 | import Test.Spec (Spec, describe, it) 40 | import Test.Spec.Assertions (shouldEqual) 41 | 42 | import Example (add') 43 | 44 | spec :: Spec Unit 45 | spec = 46 | describe "Example" do 47 | describe "add'" do 48 | it "returns sum" do 49 | (add' 1 1) `shouldEqual` 2 50 | ``` 51 | QuickCheck is supported. 52 | ```purescript 53 | module QuickCheckExampleSpec where 54 | 55 | import Prelude 56 | import Test.QuickCheck ((===)) 57 | import Test.Spec (Spec, describe, it) 58 | import Test.Spec.QuickCheck (quickCheck) 59 | 60 | spec :: Spec Unit 61 | spec = 62 | describe "QuickCheck" do 63 | it "works" $ 64 | quickCheck \n -> (n * 2 / 2) === n 65 | ``` 66 | 67 | ## Timeout 68 | 69 | 12 seconds 70 | 71 | ## Packages 72 | 73 | - `prelude` 74 | - `console` 75 | - `debug` 76 | - `effect` 77 | - `bigints` 78 | - `rationals` 79 | - `profunctor-lenses` 80 | - `spec` 81 | - `spec-discovery` 82 | - `spec-quickcheck` 83 | 84 | Packages are managed with [`psc-package`](https://github.com/purescript/psc-package) using package set [`psc-0.12.2-20190119`](https://github.com/purescript/package-sets/tree/psc-0.12.2-20190119). See [`packages.json`](https://github.com/purescript/package-sets/blob/psc-0.12.2-20190119/packages.json) for versions. 85 | 86 | Feel free to [open issues](https://github.com/Codewars/codewars-runner-cli/issues/new) for additional packages. 87 | 88 | ## Services 89 | 90 | None 91 | 92 | ## Language ID 93 | 94 | `purescript` 95 | -------------------------------------------------------------------------------- /content/authoring/guidelines/preloaded.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Writing Preloaded Code 3 | tags: [authoring, reference] 4 | --- 5 | 6 | The preloaded code snippet, created by the kata author or translator, can be used to reduce boilerplate code, but can cause problems when used incorrectly. To ensure the quality of the kata, it should conform to a set of guidelines presented below. 7 | 8 | This article contains a set of guidelines for kata authors and translators to create good code snippets for their kata. They were collected to help ensure that kata and translations are of sufficient quality and kata maintenance will be as easy as possible. 9 | 10 | ## Accessibility of Preloaded Code 11 | 12 | - The preloaded code snippet is code, and, as such, should conform to [Codewars General Coding Guidelines][authoring-guidelines-general]. 13 | - **Do not put any code in preloaded which should not be called by the submitted solution.** Code placed in this snippet can be called (and for some languages even modified or redefined) by the submitted solution, and any data stored here can be read or modified programmatically. It should not contain anything critical used by tests to validate the correctness of the solution. 14 | - **Be aware that the user solution can read the preloaded code snippet**. It should not contain any information which would reveal details of the solution or tests. 15 | - **Do not hide useful information in the preloaded code snippet.** The preloaded code snippet can be used to reduce boilerplate, and its code is available to all other parts of the solution. It may be tempting to put data or types in preloaded code which should be shared among the user solution, sample tests, and submission tests. However, since the contents of the preloaded code are not displayed anywhere in the user interface, important information needed to solve the challenge may be hidden from the user. This is especially problematic for users who would like to work on the kata in their local IDE, but now are missing some pieces necessary to set up their local environment. If you use the preloaded code snippet to reduce boilerplate code, consider adding necessary information to the kata description as well, preferably in a [language conditional block][markdown-extensions]. 16 | 17 | 18 | [authoring-guidelines-general]: /authoring/guidelines/ 19 | [markdown-extensions]: /references/markdown/extensions/ 20 | -------------------------------------------------------------------------------- /docusaurus.config.js: -------------------------------------------------------------------------------- 1 | const { createHighlighter } = require("./src/remark/shiki"); 2 | 3 | /** @type {import('@docusaurus/types').DocusaurusConfig} */ 4 | module.exports = { 5 | title: "The Codewars Docs", 6 | tagline: "Achieve mastery through challenge", 7 | url: "https://docs.codewars.com", 8 | baseUrl: "/", 9 | onBrokenLinks: "throw", 10 | onBrokenMarkdownLinks: "warn", 11 | favicon: "favicon.ico", 12 | organizationName: "codewars", 13 | projectName: "docs", 14 | // https://docusaurus.io/docs/next/api/themes/configuration 15 | themeConfig: { 16 | docs: { 17 | sidebar: { 18 | hideable: true, 19 | }, 20 | }, 21 | colorMode: { 22 | defaultMode: "dark", 23 | }, 24 | algolia: { 25 | // Search only API key 26 | apiKey: "651420d53bdf2d24b6719c6777dc69a4", 27 | indexName: "codewars-docs", 28 | appId: "2O5VWTLFC8", 29 | contextualSearch: false, 30 | }, 31 | navbar: { 32 | title: null, 33 | hideOnScroll: true, 34 | logo: { 35 | alt: "Codewars Logo", 36 | src: "logo-light.svg", 37 | srcDark: "logo-dark.svg", 38 | href: "https://www.codewars.com/", 39 | }, 40 | items: [ 41 | { 42 | label: "Docs", 43 | activeBaseRegex: "/(?!search)", 44 | position: "left", 45 | to: "/", 46 | }, 47 | { 48 | href: "https://github.com/codewars", 49 | position: "right", 50 | className: "header-github-link", 51 | "aria-label": "GitHub", 52 | }, 53 | ], 54 | }, 55 | footer: { 56 | links: [], 57 | copyright: `Copyright © ${new Date().getFullYear()} Codewars`, 58 | }, 59 | }, 60 | presets: [ 61 | [ 62 | "@docusaurus/preset-classic", 63 | { 64 | docs: { 65 | path: "content", 66 | routeBasePath: "/", 67 | sidebarPath: require.resolve("./sidebars.js"), 68 | editUrl: "https://github.com/codewars/docs/edit/master/", 69 | beforeDefaultRemarkPlugins: [ 70 | createHighlighter({ 71 | themes: ["github-dark-dimmed", "github-light"], 72 | }), 73 | ], 74 | }, 75 | blog: false, 76 | theme: { 77 | customCss: require.resolve("./src/css/custom.css"), 78 | }, 79 | }, 80 | ], 81 | ], 82 | plugins: ["./sitePlugin.js"], 83 | }; 84 | -------------------------------------------------------------------------------- /content/concepts/kata.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: What is Kata? 3 | tags: [concept] 4 | --- 5 | 6 | On Codewars, kata are code challenges focused on improving skill and technique. Some train programming fundamentals, while others focus on complex problem solving. Others are puzzles meant to test your creative problem solving, while others are based on real world coding scenarios. 7 | 8 | The term was first coined by [Dave Thomas](https://en.wikipedia.org/wiki/Dave_Thomas_%28programmer%29), co-author of the book [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) as an acknowledgment to the Japanese concept of kata in the martial arts. Dave's version of the concept defines a code kata as an exercise in programming which helps a programmer sharpen their skills through practice and repetition. 9 | 10 | ## Working with kata 11 | 12 | Codewars supports users in many ways so their training with kata is maximally effective: 13 | 14 | - They can set up one of available [training routines][training-routines]. 15 | - Users can run [test cases][kata-tests] against their solution and solve kata using Test Driven Development approach. 16 | - Users can take a part in a [discourse][kata-discussion] on every kata, to ask for help, or help others. 17 | - Kata can be bookmarked or grouped into [collections][kata-collections] for easier management, categorization, or sharing with others. 18 | - Users can view [solutions][kata-solutions] of other people after they manage to solve the kata or unlock them. 19 | 20 | ## Contributing to the site 21 | 22 | Users can also contribute to existing kata in various ways: 23 | 24 | - After a kata is solved, users can cast their [satisfaction vote][kata-satisfaction-rating] for a kata to let others know how they like it. 25 | - Users can solve [beta kata][kata-beta-process] to evaluate them before they get accepted. 26 | - Authors can create new kata and put them in [beta][kata-beta-process]. 27 | - Translators can [create new language versions][kata-translations] (translations) of kata. 28 | 29 | 30 | [training-routines]: /concepts/kata/training-routines/ 31 | [kata-tests]: /concepts/kata/tests/ 32 | [kata-discussion]: /concepts/kata/discourse/ 33 | [kata-collections]: /concepts/kata/collections/ 34 | [kata-solutions]: /concepts/kata/solutions/ 35 | [kata-satisfaction-rating]: /concepts/kata/satisfaction-rating/ 36 | [kata-beta-process]: /concepts/kata/beta-process/ 37 | [kata-translations]: /concepts/kata/translations/ 38 | -------------------------------------------------------------------------------- /content/languages/rust/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Rust 3 | description: Rust on Codewars 4 | slug: /languages/rust 5 | tags: [rust] 6 | --- 7 | 8 | 9 | ## Versions 10 | 11 | - 1.66 (`edition = "2021"`) 12 | 13 | The following profiles are used to get decent performance in tests: 14 | 15 | ```toml 16 | [profile.dev] 17 | opt-level = 1 18 | [profile.dev.package."*"] 19 | opt-level = 3 20 | 21 | [profile.test] 22 | opt-level = 1 23 | [profile.test.package."*"] 24 | opt-level = 3 25 | ``` 26 | 27 | ## Test Frameworks 28 | 29 | Rust kata use the built-in Rust support for testing, with test functions marked with `#[test]`. 30 | 31 | ## Example 32 | 33 | Solution and tests are concatenated to `src/lib.rs`. 34 | 35 | ```rust 36 | pub fn add(x: i32, y: i32) -> i32 { x + y } 37 | ``` 38 | 39 | All the tests _should_ be in a child module named `tests`: 40 | ```rust 41 | #[cfg(test)] 42 | mod tests { 43 | use super::*; 44 | #[test] 45 | fn adds_i32() { 46 | assert_eq!(add(1, 1), 2); 47 | } 48 | } 49 | ``` 50 | 51 | The optional preloaded code is a child module `preloaded` at `src/preloaded.rs`. 52 | Rust's module system is explicit, so you need to declare it with `mod preloaded;` to use it. 53 | 54 | See the unit testing chapter in [the book](https://doc.rust-lang.org/book/ch11-01-writing-tests.html) and 55 | [Rust By Example](https://doc.rust-lang.org/rust-by-example/testing/unit_testing.html) for more. 56 | 57 | [codewars/rust-devcontainer](https://github.com/codewars/rust-devcontainer) can be used if you'd like to solve locally. 58 | 59 | ## Timeout 60 | 12 seconds 61 | 62 | ## Packages 63 | 64 | ### 1.66 65 | 66 | ```toml 67 | [dependencies] 68 | bit-set = "0.5.3" 69 | chrono = "0.4.23" 70 | either = "1.8.0" 71 | fancy-regex = "0.10.0" 72 | futures = "0.3.25" 73 | im = "15.1.0" 74 | itertools = "0.10.5" 75 | lazy_static = "1.4.0" 76 | num = { version = "0.4.0", features = ["rand"] } 77 | once_cell = "1.16.0" 78 | rand = "0.8.5" 79 | regex = "1.7.0" 80 | serde = { version = "1.0.150", features = ["derive"] } 81 | serde_json = "1.0.89" 82 | text_io = "0.1.12" 83 | thiserror = "1.0.37" 84 | tokio = { version = "1.23.0", features = ["full"] } 85 | tokio-util = { version = "0.7.4", features = ["full"] } 86 | 87 | [dev-dependencies] 88 | quickcheck = "1.0.3" 89 | quickcheck_macros = "1.0.0" 90 | float_eq = "1.0.1" 91 | ``` 92 | 93 | ## Services 94 | 95 | None 96 | 97 | ## Language ID 98 | 99 | `rust` 100 | -------------------------------------------------------------------------------- /content/languages/factor/testest.md: -------------------------------------------------------------------------------- 1 | --- 2 | tags: 3 | - factor 4 | - reference 5 | - testing 6 | --- 7 | 8 | # testest 9 | 10 | To run Factor tests, Codewars currently uses a custom test vocabulary, published and available in [this GitHub repository][test-framework-repo]. 11 | 12 | ## Basic Usage 13 | 14 | ```factor 15 | USING: solution-vocabulary tools.testest ; 16 | IN: solution-vocabulary.tests 17 | 18 | : run-tests ( -- ) 19 | "Example Tests" describe#{ 20 | "Example test case" it#{ 21 | <{ 1 1 add -> 2 }> 22 | }# 23 | 24 | "Another test case" it#{ 25 | <{ 3 double -> 6 }> 26 | <{ 0 double -> 0 }> 27 | }# 28 | }# 29 | 30 | MAIN: run-tests 31 | ``` 32 | 33 | ## Words and Syntax 34 | 35 | #### `describe#{` 36 | 37 | Starts a new block of tests, taking a string off the stack as the title of the block. Terminated with the `}#` word. 38 | 39 | #### `it#{` 40 | 41 | Starts a new test group, taking a string off the stack as the title of the block. Terminated with the `}#` word. 42 | 43 | #### `<{ ...inputs -> ...expected }>` 44 | 45 | Creates a unit test, by executing the values in `...inputs`, then executing the values in `...expected` and comparing the resulting stacks. If they match, the test is passed, otherwise the test is failed. On failure, the stacks are packed into a tuple (under `got` and `expected` slots, respectively) and pushed onto the stack to be available for the `test-failed.` quotation. 46 | 47 | #### `test-passed.` 48 | 49 | `test-passed.` is a symbol which is bound to a quotation with stack effect `( -- )`. When a unit test passes, this quotation will be called. This can be used to create [custom result messages](/languages/factor/authoring#custom-result-messages). 50 | 51 | #### `test-failed.` 52 | 53 | `test-passed.` is a symbol which is bound to a quotation with stack effect `( assert-sequence -- )`. When a unit test fails, the values on the left and right side of the test will be collected into sequences, and stored in tuple under slots `got` and `expected` respectively. This tuple will be pushed onto the stack, and then this quotation will be called. This can be used to create [custom result messages](/languages/factor/authoring#custom-result-messages). 54 | 55 | ## Acknowledgements 56 | 57 | `testest` was authored by [@nomennescio](https://github.com/nomennescio). 58 | 59 | [test-framework-repo]: https://github.com/codewars/testest 60 | 61 | 62 | 67 | -------------------------------------------------------------------------------- /content/concepts/kata/discourse.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kata Discourse 3 | tags: [concept] 4 | --- 5 | 6 | 7 | _TBD: this page was imported from old CW wiki and needs to be reviewied/redacted._ 8 | 9 | Each kata has its own discourse page where you can discuss. This is also a place for you to log any issues, suggestions or questions. 10 | 11 | > TODO: complete 12 | 13 | ## Comment Labels 14 | 15 | There are 3 different labels that you can set on your comment. If you are just having normal conversation, you don't have to set a label - but please do if any of the following are relevant. 16 | 17 | ### Issues 18 | 19 | If you find an issue with the kata, such as broken test cases, buggy output or incorrect descriptions, please apply the `Issue` label to the comment. This will notify the author of any issues, as well as making it more obvious that there are problems with the content. 20 | Logging issues is OK for things like needing random test cases, or changes that are critical to completing the kata. _Keep an eye out for duplicates:_ please don't file the same issue as someone else. 21 | If you want to try to bump the issue, reply to the existing one instead - though commenting for the purpose of bring attention to the issue isn't necessary if it was recently created. 22 | 23 | ### Suggestions 24 | 25 | A suggestion is something that could be improved but isn't required to be. During the beta process suggestions are less common, though still relevant. Please see note above about the post-beta process. Use suggestions when the kata could be improved but there isn't a critical issue preventing warriors from completing it. 26 | 27 | ### Questions 28 | 29 | If you are struggling to complete the kata, you can go discuss it. Label your comment as a question so that others can more easily spot it as such. 30 | 31 | ## Spoiler Comments 32 | 33 | When you create a comment, there is an option for marking it as a spoiler. You should mark any comment as a spoiler if it contains code within it that might give the solution away to other users. 34 | 35 | If you don't remember to do it, other users can mark the comment as a spoiler later - but please try to remember to mark this yourself when appropriate. 36 | 37 | ## Resolving Comments 38 | 39 | Comments with labels can be resolved to indicate they are no longer relevant/active. The author of the original comment can do this, as well as the kata author, warriors with the "Resolve Comment" permission, and site admins. 40 | 41 | Resolving comments are important, especially during the beta process, because a kata cannot be approved unless all issues are resolved. 42 | -------------------------------------------------------------------------------- /content/curation/guidelines/translation.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Translation Reviewing Guidelines 3 | --- 4 | 5 | This article contains a set of guidelines, which can be used by reviewers to determine whether a pending translation meets quality requirements to be approved and become available for users to train on. They were collected to help ensure that translations are of sufficient quality and users' experience will be as good as possible. 6 | 7 | :::note 8 | The guidelines are to be followed by every user reviewing and potentially approving a translation, including the author of the translated kata. 9 | ::: 10 | 11 | ## Review 12 | 13 | - **The translation must be reviewed before it's approved.** If the reviewer is not familiar with the language of the translation, they should ask other users for help. 14 | - **The review should be as complete as possible,** including all applicable steps mentioned in [Curating a Translation HOWTO][howto-review-translation] 15 | - **Conformity to [translation authoring guidelines][guidelines-authoring-translation] should be verified.** All applicable guidelines should be followed by the translator. 16 | - Reviewers and users other than the original translator are allowed to **fix issues in pending translations.** 17 | 18 | 19 | ## Approval 20 | 21 | - A translation can be approved only if the review confirms that it is of sufficient quality, it holds to all applicable quality guidelines, and all reported issues have been addressed. 22 | - **Suggestion posts announcing the translation should be marked as resolved**. 23 | - **Approvers should keep responsibility for the issues in translations they approved.** You should actively maintain all problems which slipped through your review and ended up in an approved translation: fix issues, consider suggestions, answer questions. 24 | 25 | 26 | ## Rejection 27 | 28 | - If a translation has too many issues or cannot be easily fixed, and there's justified concern that it could be approved prematurely while not keeping up to quality standards, **it should be rejected**. 29 | - **Reason why the translation was rejected should be stated** in the translation comments section. 30 | - Translation does not have to be rejected and can be left in pending state if it has some issues, all of them are reported, but the translation cannot be approved without editing (for example, due to description merge conflict). 31 | 32 | ## Maintenance 33 | 34 | - After a translation is approved, it becomes **the responsibility of the translator and the kata author** to fix any potential issues which might come up later when users attempt to submit their solution. 35 | 36 | 37 | [guidelines-authoring-translation]: /authoring/guidelines/translation/ 38 | [howto-review-translation]: /curation/translation/#review 39 | -------------------------------------------------------------------------------- /content/curation/references/approval-retirement-criteria.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Criteria for Kata Approval and Retirement 3 | sidebar_label: Criteria for Approval and Retirement 4 | tags: [reference] 5 | --- 6 | 7 | ## Eligibility for Approval 8 | 9 | As an author gets more katas approved, they become established as an experienced kata maker, and less votes will be needed for their future kata to be approved. The following table lists the requirements for a beta kata to be able to be approved: 10 | 11 |
| Average assessed rank | 15 |Required satisfaction % | 16 |Required votes (by number of author's approved kata) |
17 | |||
|---|---|---|---|---|---|
| 20 | | 21 | | <10 | 22 |<20 | 23 |<30 | 24 |30+ | 25 |
| White | 30 |80+ | 31 |12 | 32 |10 | 33 |8 | 34 |6 | 35 |
| Yellow | 38 |80+ | 39 |10 | 40 |8 | 41 |7 | 42 |5 | 43 |
| Blue | 46 |75+ | 47 |8 | 48 |6 | 49 |5 | 50 |4 | 51 |
| Purple | 54 |70+ | 55 |5 | 56 |4 | 57 |3 | 58 |3 | 59 |