Useful & simple app make me test

Writing Extensions¶ ↑

To define a plugin, add a file named minitest/XXX_plugin.rb to your project/gem. That file must be discoverable via ruby’s LOAD_PATH (via rubygems or otherwise). Minitest will find and require that file using Gem.find_files. It will then try to call during startup. The option processor will also try to call passing the OptionParser instance and the current options hash. This lets you register your own command-line options. Here’s a totally bogus example:

# minitest/bogus_plugin.rb:

module Minitest
  def self.plugin_bogus_options(opts, options)
    opts.on "--myci", "Report results to my CI" do
      options = true
      options = get_myci_addr
      options = get_myci_port
    end
  end

  def self.plugin_bogus_init(options)
    self.reporter << MyCI.new(options) if options
  end
end

Adding custom reporters

Minitest uses composite reporter to output test results using multiple reporter instances. You can add new reporters to the composite during the init_plugins phase. As we saw in above, you simply add your reporter instance to the composite via .

defines the API for reporters. You may subclass it and override any method you want to achieve your desired behavior.

start

Called when the run has started.

record

Called for each result, passed or otherwise.

report

Called at the end of the run.

passed?

Called to see if you detected any problems.

Using our example above, here is how we might implement MyCI:

# minitest/bogus_plugin.rb

module Minitest
  class MyCI < AbstractReporter
    attr_accessor :results, :addr, :port

    def initialize options
      self.results = []
      self.addr = options
      self.port = options
    end

    def record result
      self.results << result
    end

    def report
      CI.connect(addr, port).send_results self.results
    end
  end

  # code from above...
end

Зачем нужны тесты?

При написании функции мы обычно представляем, что она должна делать, какое значение на каких аргументах выдавать.

В процессе разработки мы время от времени проверяем, правильно ли работает функция. Самый простой способ проверить – это запустить её, например в консоли, и посмотреть результат.

Если что-то не так, поправить, опять запустить – посмотреть результат… И так «до победного конца».

Но такие ручные запуски – очень несовершенное средство проверки.

Когда проверяешь работу кода вручную – легко его «недотестировать».

Например, пишем функцию . Написали, тестируем с разными аргументами. Вызов функции работает, а вот не работает. Поправили код – стало работать , вроде закончили. Но при этом забыли заново протестировать – упс, вот и возможная ошибка в коде.

Автоматизированное тестирование – это когда тесты написаны отдельно от кода, и можно в любой момент запустить их и проверить все важные случаи использования.

Improving the spec

What we’ve done is definitely a cheat. The function does not work: an attempt to calculate would give an incorrect result, but tests pass.

…But the situation is quite typical, it happens in practice. Tests pass, but the function works wrong. Our spec is imperfect. We need to add more use cases to it.

Let’s add one more test to check that .

We can select one of two ways to organize the test here:

1. The first variant – add one more into the same :

2. The second – make two tests:

The principal difference is that when triggers an error, the block immediately terminates. So, in the first variant if the first fails, then we’ll never see the result of the second .

Making tests separate is useful to get more information about what’s going on, so the second variant is better.

And besides that, there’s one more rule that’s good to follow.

One test checks one thing.

If we look at the test and see two independent checks in it, it’s better to split it into two simpler ones.

So let’s continue with the second variant.

The result:

As we could expect, the second test failed. Sure, our function always returns , while the expects .

Исправление спецификации

Функция, конечно, ещё не готова, но тесты проходят. Это ненадолго 🙂

Здесь мы видим ситуацию, которая (и не обязательно при ленивом программисте!) бывает на практике – да, есть тесты, они проходят, но функция (увы!) работает неправильно.

С точки зрения BDD, ошибка при проходящих тестах – вина спецификации.

В первую очередь не реализация исправляется, а уточняется спецификация, пишется падающий тест.

Сейчас мы расширим спецификацию, добавив проверку на .

Здесь есть два варианта организации кода:

1. Первый вариант – добавить в тот же :

2. Второй вариант – сделать два теста:

Их принципиальное различие в том, что если обнаруживает ошибку, то он тут же прекращает выполнение блока . Поэтому в первом варианте, если вдруг первый «провалился», то про результат второго мы никогда не узнаем.

Таким образом, разделить эти тесты может быть полезно, чтобы мы получили больше информации о происходящем.

Кроме того, есть ещё одно правило, которое желательно соблюдать.

Один тест тестирует ровно одну вещь.

Если мы явно видим, что тест включает в себя совершенно независимые проверки – лучше разбить его на два более простых и наглядных.

По этим причинам второй вариант здесь предпочтительнее.

Результат:

Как и следовало ожидать, второй тест не проходит. Ещё бы, ведь функция всё время возвращает .

INSTALL:¶ ↑

sudo gem install minitest

On 1.9, you already have it. To get newer candy you can still install the gem, and then requiring “minitest/autorun” should automatically pull it in. If not, you’ll need to do it yourself:

gem "minitest"     # ensures you"re using the gem, and not the built-in MT
require "minitest/autorun"

# ... usual testing stuffs ...

DO NOTE: There is a serious problem with the way that ruby 1.9/2.0 packages their own gems. They install a gem specification file, but don’t install the gem contents in the gem path. This messes up Gem.find_files and many other things (gem which, gem contents, etc).

Just install minitest as a gem for real and you’ll be happier.

Speed Test Flow

When you request a speed test the test data is created randomly. You’re not downloading or uploading any real information. This means every TestMy.net speed test is unique, making host caching of the data difficult. When your speed test starts so does a timer, precision of which is measured in ten thousandths of a second. Also, data sizes are precise to the individual byte.

Once the flow of information is finished the timer is stopped and your results are calculated. Test results are calculated first with a simple equation, (size / time) and the resulting number is used to calculate all of your final results. Your result is then compared against your own previous results as well as to other connections in your area, on your host and across the Internet.

At TestMy.net you’re testing more than just your connection.  Because of the way TMN is designed at higher connection speeds it’s a great gauge of browser and computer performance.  Its abilities to detect issues with your computer extend beyond your Internet connection.  TMN picks up on issues other speed tests are designed to not notice.  Other speed tests are usually designed with one goal in mind, achieve the fastest result.  Make the providers look good.  TestMy.net is made by a consumer for the consumer.

Improper TCP settings, bad modems and even slow hard drive performance are only a few issues TestMy.net has been known to reflect when others don’t. Why don’t other speed tests see the same issues? Almost all other speed tests are well known to adjust results, often ignoring the exact variables you come to test. TestMy.net does not adjust anything, from start to finish — everything is calculated.

Вложенный describe

Функция и цикл , очевидно, нужны друг другу, но не нужны для других тестов, которые мы добавим в дальнейшем. Они образуют единую группу, задача которой – проверить возведение в -ю степень.

Будет правильно выделить их, при помощи вложенного блока :

Вложенный объявит новую «подгруппу» тестов, блоки которой запускаются так же, как и обычно, но выводятся с подзаголовком, вот так:

В будущем мы сможем добавить другие тесты и блоки со своими вспомогательными функциями.

before/after и beforeEach/afterEach

В каждом блоке можно также задать функции , которые будут выполнены до/после запуска тестов, а также , которые выполняются до/после каждого .

Например:

Последовательность будет такой:

Открыть пример с тестами в песочнице

Как правило, () используют, если необходимо произвести инициализацию, обнулить счётчики или сделать что-то ещё в таком духе между тестами (или их группами).

Which Quiz do You Want to Create?

Multiple Choice

True / FalseTest

SelectionQuiz

Multiple Choice Quiz

In a Multiple Choice Quiz, only one of several answers is correct.

Suitable for:
✓ Knowledge quizzes and trivia tests

Not suitable for:
✗ Personality tests and love tests

» Example» Word template

True / False Test

You can define if the «right» or the «wrong» answer should be counted as a correct one.

Suitable for:
✓ Knowledge quizzes and trivia tests
✗ Personality tests and love tests

» Example

Selection Quiz

Each possible answer can be coupled to a score value. There are no wrong answers, only answers with different score values. The result depends on the sum value.

Suitable for:
✓ Personality tests and love tests

Not suitable for:
✗ Knowledge quizzes and trivia tests

» Example» Word template

Tube Quiz

Purity Test

Test aboutYourself

Tube Quiz

In a Tube Quiz, you categorize the answers. The results will be the most chosen category.

Suitable for:
✓ Personality tests and love tests

Not suitable for:
✗ Knowledge quizzes and trivia tests

» Example» Word template

Purity Test

The ‘Yes’ answers are counted. The more ‘Yes’ answers, the more pure you are.

Not suitable for:
✗ Personality tests and love tests
✗ Knowledge quizzes and trivia tests

» Example» Word template

Test about Yourself

If you create a test about yourself, you can share it with your friends and see how well they know you. Only one of several answers is correct.

» Example» Word template

Fan fiction

Picture List

(Top) List

Fan fiction

You can create your own fan fiction / story with up to 100 chapters. You can add a picture to each chapter.

1

John
Hello, my name is John. I have lived a long life. I had everything that people would dream
of. Money, women and a huge house, But what brings you the best hand crafted gold chandelier if you
know someone is out there.
Someone who would’ve been able to love only you, If you didn’t make this one mistake.

» Continue reading

» Example

Picture List

Publish your Picture List about a specific topic, or show your own pictures to the whole world.

(Top) List

Create any list, for example «Top 10 most beautiful women in the world» or «Top 20 best football clubs».

Routing Distribution

TestMy.net has a network of servers. If you suspect a connection issue use “Servers” option to test against other locations. This can help diagnose whether an issue is due to Internet routing or if it has to do with your home network and/or computer itself.

Web Browser Performance

TestMy.net is the first and only truly accurate HTML5 & PHP driven speed test online. Other online speed tests require third party applications, TMN uses only your web browser — no Flash, no Java. This makes TestMy’s speed test more sensitive to browser misconfiguration and is an excellent way to highlight performance differences between browsers.

Users of TMN can see all browsers are not created equally. Since early development in 1996 this speed test has never required anything more than an Internet connected web browser. Don’t let other so-called «tests» fool you… TestMy.net is the original truly accurate browser based Internet speed test.

Другие assert

Обратим внимание, в спецификации выше использована проверка не , как раньше, а. Такая проверка выдаёт ошибку, если значение выражения при приведении к логическому типу не

Она потребовалась, потому что сравнивать с обычным способом нельзя: не равно никакому значению, даже самому себе, поэтому не подойдёт.

Кстати, мы и ранее могли бы использовать вместо . Оба этих проверяют одно и тоже.

Однако, между этими вызовами есть отличие в деталях сообщения об ошибке.

При «упавшем» в примере выше мы видим , то есть просто «что-то пошло не так», а при будут дополнительные подробности: .

Поэтому рекомендуется использовать именно ту проверку, которая максимально соответствует задаче.

Вот самые востребованные -проверки, встроенные в Chai:

• – проверяет что является в логическом контексте.
• – проверяет равенство .
• – проверяет строгое равенство .
• , – проверки, обратные двум предыдущим.
• – проверяет, что
• – проверяет, что
• …более полный список – в документации

В нашем случае хорошо бы использовать проверку , и такой метод существует, но сейчас мы рассматриваем самый общий метод . В этом случае для того, чтобы сделать сообщение об ошибке понятнее, желательно добавить к описание.

Все вызовы позволяют дополнительным последним аргументом указать строку с описанием ошибки, которое выводится, если не проходит.

Добавим описание ошибки в конец наших :

Теперь результат теста гораздо яснее говорит о том, что не так:

В коде тестов выше можно было бы добавить описание и к , указав в конце: , но с равенством обычно и так всё понятно, поэтому мы так делать не будем.

Development of “pow”: the spec

Let’s say we want to make a function that raises to an integer power . We assume that .

That task is just an example: there’s the operator in JavaScript that can do that, but here we concentrate on the development flow that can be applied to more complex tasks as well.

Before creating the code of , we can imagine what the function should do and describe it.

Such description is called a specification or, in short, a spec, and contains descriptions of use cases together with tests for them, like this:

A spec has three main building blocks that you can see above:

What functionality we’re describing. In our case we’re describing the function . Used to group “workers” – the blocks.

In the title of we in a human-readable way describe the particular use case, and the second argument is a function that tests it.

The code inside block, if the implementation is correct, should execute without errors.

Functions are used to check whether works as expected. Right here we’re using one of them – , it compares arguments and yields an error if they are not equal. Here it checks that the result of equals . There are other types of comparisons and checks, that we’ll add later.

The specification can be executed, and it will run the test specified in block. We’ll see that later.

Why we need tests?

When we write a function, we can usually imagine what it should do: which parameters give which results.

During development, we can check the function by running it and comparing the outcome with the expected one. For instance, we can do it in the console.

If something is wrong – then we fix the code, run again, check the result – and so on till it works.

But such manual “re-runs” are imperfect.

When testing a code by manual re-runs, it’s easy to miss something.

For instance, we’re creating a function . Wrote some code, testing: works, but doesn’t work. We fix the code and now works. Looks complete? But we forgot to re-test . That may lead to an error.

That’s very typical. When we develop something, we keep a lot of possible use cases in mind. But it’s hard to expect a programmer to check all of them manually after every change. So it becomes easy to fix one thing and break another one.

Automated testing means that tests are written separately, in addition to the code. They run our functions in various ways and compare results with the expected.

Our Tips for an Exciting Quiz

1.	Designing a quiz takes a lot of time. You will need at least 30 minutes!
2.	Once you have designed your quiz, you cannot make any changes! So design it with the utmost care!
3.	Start by writing your introduction, questions and answers using a word processing program. This will save you online costs and you cannot lose your work if any problems with the internet connection appear. This also enables you to use the spell checker. Finally you can transfer your data to AllTheTests.com using the copy (CTRL + C) and paste (CTRL + V) function.
4.	Write a gripping introduction!
6.	For every question you must enter three to five answering options!
7.	You can enter four different evaluation texts for praising or criticising your participants for their knowledge.
8.	Please note that your quiz will not appear immediately on AllTheTests.com. Each quiz needs to be checked for its contents (see points 1 and 2)! However, you can incorporate your quiz immediately into your home page, where it will function right away!

MIUI 12 Global набор тестировщиков в Mi Pilot

На официальной странице в глобальной ветке Mi Community разместили информацию про набор тестеров для глобальной стабильной MIUI 12 Global Stable Beta.

Какие смартфоны Xiaomi первые?

Первыми в тестировании обновления MIUI 12 примут участие три модели телефонов Сяоми:

• Mi 9;
• Mi 9T (Redmi K20);
• Mi 9T Pro (Redmi K20 Pro).

Как стать тестировщиком MIUI 12 Global и попасть в Mi Pilot?

Подать заявку на участие в Mi Pilot может любой пользователь. Хорошая новость в том, что процедура подачи заявки и участии в тестировании значительно упрощена, по сравнению с регистрацией на тестирование китайской прошивки.

Заполняем все необходимые поля:

Указываем электронный адрес (важно: не используйте «левый» e-mail).
Пишем свой Mi ID (смотрим в настройках профиля в Mi Community).
Выбираем модель телефона Xiaomi из трех предложенных.
Выбираем вариант глобальной прошивки, который будете тестировать (Software Version).
Заполнив все пункты, нажимаем «Отправить» заявку.
Вступить в группу в Telegram, указанную на этой странице (для каждой модели телефона своя группа в Телеграме).

В 4-м пункте есть четыре варианта на выбор:

• Mi – классическая глобальная прошивка (оптимальный вариант).
• EU – европейская (обычно такая прошивка на телефонах купленных в Европе, также в Украине официально продают новые телефоны Xiaomi с такой прошивкой).
• RU – русская (имеется ввиду MIUI 12 Russia).
• JD – индонезийская версия (встречается достаточно редко).

Рекомендуется выбирать именно «Mi»

Кто первым подаст, у того больше шанс на одобрение и вступление в Mi Pilot.

Основные требования:

Основной критерий: быть опытным пользователем телефона Xiaomi и фирменной оболочки MIUI. Приоритет в одобрении заявок будет отдаваться тем пользователям, которые ранее принимали участие в тестировании прошлых версий.

Вы должны уметь устанавливать прошивку, создавать и отправлять отчёты. Полностью готовы сотрудничать с инженерами и сообщать подробную информацию о проблемах.

Уметь сделать резервную копию, и знать, как откатить обновление на Xiaomi, в случая не удачного обновления или перепрошивки.

Что важно знать?

1) Подавая заявку вы будете тестировать исключительно прошивку MIUI 12 Global Stable Beta.

2) После заполнения заявки необходимо дождаться, чтобы её одобрили. Если вы соответствуете всем критериям и вашу заявку официально одобрили, вы окажитесь в группе тестировщиков глобальной стабильной бета-версии. Также вы получите ссылку на группу в Telegram.

3) Чтобы вы могли получать уведомления через OTA, убедитесь, что ваше устройство имеет стабильную бета-версию ROM.

4) Перед обновлением необходимо сделать резервную копию ваши данных.

The development flow

The flow of development usually looks like this:

1. An initial spec is written, with tests for the most basic functionality.
2. An initial implementation is created.
3. To check whether it works, we run the testing framework Mocha (more details soon) that runs the spec. While the functionality is not complete, errors are displayed. We make corrections until everything works.
4. Now we have a working initial implementation with tests.
5. We add more use cases to the spec, probably not yet supported by the implementations. Tests start to fail.
6. Go to 3, update the implementation till tests give no errors.
7. Repeat steps 3-6 till the functionality is ready.

So, the development is iterative. We write the spec, implement it, make sure tests pass, then write more tests, make sure they work etc. At the end we have both a working implementation and tests for it.

Let’s see this development flow in our practical case.

The first step is already complete: we have an initial spec for . Now, before making the implementation, let’s use few JavaScript libraries to run the tests, just to see that they are working (they will all fail).

maketestcc.h

Header file with utility functions for formatting tests.
Requires c++ initialiser lists.
assert_* functions are implemented as functions.
TEST_* objects are stl containers.
This header allows neater formatting and labelling of test code.
In future, timing information will be added.

assert specialisations:

• assert_are_equal (x, y) : assert two values are equal, using == operator
• assert_are_equal (x, y, t) : assert two values are within a given tolerance, using abs() and —

Prettyfying structures:

• TEST (string_name, lambda (void)) : test function with name and code.
• TEST_SET (string_name, list of TESTs) : test set
• TEST_SUITE (string_name, list of TEST_SETs): test suite.
• RUN_TEST (string_name) : name of the test suite to execute.

Nested describe

We’re going to add even more tests. But before that let’s note that the helper function and should be grouped together. We won’t need in other tests, it’s needed only in : their common task is to check how raises into the given power.

Grouping is done with a nested :

The nested defines a new “subgroup” of tests. In the output we can see the titled indentation:

In the future we can add more and on the top level with helper functions of their own, they won’t see .

and

We can setup functions that execute before/after running tests, and also functions that execute before/after every .

For instance:

The running sequence will be:

Open the example in the sandbox.

Usually, and are used to perform initialization, zero out counters or do something else between the tests (or test groups).

LICENSE:¶ ↑

(The MIT License)

Copyright Ryan Davis, seattle.rb

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ‘AS IS’, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The spec in action

Here in the tutorial we’ll be using the following JavaScript libraries for tests:

• Mocha – the core framework: it provides common testing functions including and and the main function that runs tests.
• Chai – the library with many assertions. It allows to use a lot of different assertions, for now we need only .
• Sinon – a library to spy over functions, emulate built-in functions and more, we’ll need it much later.

These libraries are suitable for both in-browser and server-side testing. Here we’ll consider the browser variant.

The full HTML page with these frameworks and spec:

The page can be divided into five parts:

1. The – add third-party libraries and styles for tests.
2. The with the function to test, in our case – with the code for .
3. The tests – in our case an external script that has from above.
4. The HTML element will be used by Mocha to output results.
5. The tests are started by the command .

The result:

As of now, the test fails, there’s an error. That’s logical: we have an empty function code in , so returns instead of .

For the future, let’s note that there are more high-level test-runners, like karma and others, that make it easy to autorun many different tests.

maketest.h

Header file with utility functions.
assert_* functions are implemented with the preprocessor.
TEST* functions are implemented with the preprocessor.
timing information is implemented by functions which use std::function.
In future, this dependency will be removed so this header can be used in plain c situations.

assert specialisations:

• assert_are_equal (x, y) : assert two values are equal, using == operator
• assert_are_equal_t (x, y, t) : assert two values within a given tolerance, using abs() and —
• assert_are_not_equal (x, y) : assert two values are not equal, using !=
• assert_is_true (x) : assert x is not equal to 0, using !=
• assert_is_false (x) : assert x is equal to 0, using ==

Timing wrapper functions:

• TEST(x) : wrap a function x with timing information
• TEST_GROUP (x) : wrap a function x with timing information as a group
• TEST_SUITE (x) : wrap a function x with timing information as a suite

Summary

In BDD, the spec goes first, followed by implementation. At the end we have both the spec and the code.

The spec can be used in three ways:

1. As Tests – they guarantee that the code works correctly.
2. As Docs – the titles of and tell what the function does.
3. As Examples – the tests are actually working examples showing how a function can be used.

With the spec, we can safely improve, change, even rewrite the function from scratch and make sure it still works right.

That’s especially important in large projects when a function is used in many places. When we change such a function, there’s just no way to manually check if every place that uses it still works right.

Without tests, people have two ways:

1. To perform the change, no matter what. And then our users meet bugs, as we probably fail to check something manually.
2. Or, if the punishment for errors is harsh, as there are no tests, people become afraid to modify such functions, and then the code becomes outdated, no one wants to get into it. Not good for development.

Automatic testing helps to avoid these problems!

If the project is covered with tests, there’s just no such problem. After any changes, we can run tests and see a lot of checks made in a matter of seconds.

Besides, a well-tested code has better architecture.

Naturally, that’s because auto-tested code is easier to modify and improve. But there’s also another reason.

To write tests, the code should be organized in such a way that every function has a clearly described task, well-defined input and output. That means a good architecture from the beginning.

In real life that’s sometimes not that easy. Sometimes it’s difficult to write a spec before the actual code, because it’s not yet clear how it should behave. But in general writing tests makes development faster and more stable.

Later in the tutorial you will meet many tasks with tests baked-in. So you’ll see more practical examples.

Writing tests requires good JavaScript knowledge. But we’re just starting to learn it. So, to settle down everything, as of now you’re not required to write tests, but you should already be able to read them even if they are a little bit more complex than in this chapter.

Internet Speed Test

TestMy.net is a powerful broadband speed test that will test your Internet, calculate your transfer rate and output accurate, reliable and easy to understand results. TestMy.net is an independent third party and is not affiliated with your Internet service provider. Our results are unbiased because TMN has no vested interest in the outcome of your speed test.

We work for the Internet consumers not the Internet providers. First to offer the ability to log test results, test upload speed and automatically test Internet speed. TestMy.net has been pioneering the bandwidth speed test since 1996.

What makes TestMy.net Different?

TestMy.net will provide you with real-world broadband speed test results in real-world conditions. We stand for the consumer not the ISP so TestMy does not inflate scores to make your provider look better than they are or host our test servers on the edge of ISP networks. Our speed test servers are configured to maintain quality of service for thousands of miles and are hosted in locations where many popular websites are hosted. We believe this is a more accurate representation of your true speed.

Most Internet consumers don’t think about the Internet service providers responsibility in peering beyond their own network. Many Internet providers send users to their own internally hosted connection test. When you surf the net, how often are you visiting a server within your hosts network?

When you buy something do you normally trust the seller to inspect it for you?

Read more →Then why would you trust your ISP to test your Internet… TestMy.net has been a trusted speed test since 2001.

You’ll notice the ‘TiP’ or Test in Progress data on TestMy.net download test results you’ll realize that numbers can easily be altered without lying. It is common practice among other speed tests to calculate the result based on incomplete information.

Speed tests showing the maximum speed or average speeds can be HIGHLY deceiving, even experienced technicians can be tricked. The fact is, if the information used to calculate the result is altered… the result is null. The final score presented to you by TestMy.net takes everything into account, from start to finish. Nothing is altered. The ‘TiP’ data is also shown so you can interpret the results the way you want. Remember, TestMy.net is a third party and has no vested interest in your test results. Your ISP can’t say that.

FAQ¶ ↑

How to test SimpleDelegates?

The following implementation and test:

class Worker < SimpleDelegator
  def work
  end
end

describe Worker do
  before do
    @worker = Worker.new(Object.new)
  end

  it "must respond to work" do
    _(@worker).must_respond_to :work
  end
end

outputs a failure:

  1) Failure:
Worker#test_0001_must respond to work :
Expected #<Object:0x007f9e7184f0a0> (Object) to respond to #work.

Worker is a SimpleDelegate which in 1.9+ is a subclass of BasicObject. Expectations are put on Object (one level down) so the Worker (SimpleDelegate) hits and delegates down to the instance. That object doesn’t respond to work so the test fails.

You can bypass by extending the worker with . You can either do that in your setup at the instance level, like:

before do
  @worker = Worker.new(Object.new)
  @worker.extend Minitest::Expectations
end

or you can extend the Worker class (within the test file!), like:

class Worker
  include ::Minitest::Expectations
end

How to share code across test classes?

Use a module. That’s exactly what they’re for:

module UsefulStuff
  def useful_method
    # ...
  end
end

describe Blah do
  include UsefulStuff

  def test_whatever
    # useful_method available here
  end
end

Remember, simply creates test classes. It’s just ruby at the end of the day and all your normal Good Ruby Rules ™ apply. If you want to extend your test using setup/teardown via a module, just make sure you ALWAYS call super. before/after automatically call super for you, so make sure you don’t do it twice.

How to run code before a group of tests?

Use a constant with begin…end like this:

describe Blah do
  SETUP = begin
     # ... this runs once when describe Blah starts
  end
  # ...
end

This can be useful for expensive initializations or sharing state. Remember, this is just ruby code, so you need to make sure this technique and sharing state doesn’t interfere with your tests.

Why am I seeing ?

Are you running the test with Bundler (e.g. via )? If so, in order to require minitest, you must first add the to your Gemfile and run . Once it’s installed, you should be able to require minitest and run your tests.

Makefile

The magic makefile which compiles all the files matching <TEST_DIR> / <any> / <filename>.cpp into test programs.

Each .cpp file will be compiled as a separate executable, so must contain a main function (see below for an example test code file).

Requirements:

• Must be included from the main project makefile.
• Main project makefile should define a TEST_DIR variable
• TEST_DIR indicates where the .cpp files test code.
• TEST_DIR must contain a trailing directory separator.

Notes:

• Creates «bin» subdirectory under <TEST_DIR>.
• Test executables are output to <TEST_DIR>/bin.
• There is a bug when tests are in the same dir as the makefile:
  • Using an empty <TEST_DIR> means .cpp files are not discovered,
  • Using «.» for <TEST_DIR> means executables are written to .bin rather than <TEST_DIR>/bin.
  • Fixing this requires some make voodoo I’m not aware of yet.

See Makefile for a list of commands.

Итого

Итак, разработка завершена, мы получили полноценную спецификацию и код, который её реализует.

Задачи выше позволяют дополнить её, и в результате может получиться что-то в таком духе:

Открыть полный пример с реализацией в песочнице

Эту спецификацию можно использовать как:

1. Тесты, которые гарантируют правильность работы кода.
2. Документацию по функции, что она конкретно делает.
3. Примеры использования функции, которые демонстрируют её работу внутри .

Имея спецификацию, мы можем улучшать, менять, переписывать функцию и легко контролировать её работу, просматривая тесты.

Особенно важно это в больших проектах. Бывает так, что изменение в одной части кода может повлечь за собой «падение» другой части, которая её использует

Так как всё-всё в большом проекте руками не перепроверишь, то такие ошибки имеют большой шанс остаться в продукте и вылезти позже, когда проект увидит посетитель или заказчик

Бывает так, что изменение в одной части кода может повлечь за собой «падение» другой части, которая её использует. Так как всё-всё в большом проекте руками не перепроверишь, то такие ошибки имеют большой шанс остаться в продукте и вылезти позже, когда проект увидит посетитель или заказчик.

Чтобы избежать таких проблем, бывает, что вообще стараются не трогать код, от которого много что зависит, даже если его ну очень нужно переписать. Жизнь пробивается тонкими росточками там, где должна цвести и пахнуть новая функциональность.

Код, покрытый автотестами, являет собой полную противоположность этому!

Даже если какое-то изменение потенциально может порушить всё – его совершенно не страшно сделать. Ведь есть масса тестов, которые быстро и в автоматическом режиме проверят работу кода. И если что-то падает, то это можно будет легко локализовать и поправить.

Кроме того, код, покрытый тестами, имеет лучшую архитектуру.

Конечно, это естественное следствие того, что его легче менять и улучшать. Но не только.

Чтобы написать тесты, нужно разбить код на функции так, чтобы для каждой функции было чётко понятно, что она получает на вход, что делает с этим и что возвращает. Это означает ясную и понятную структуру с самого начала.

Конечно, в реальной жизни всё не так просто. Зачастую написать тест сложно. Или сложно поддерживать тесты, поскольку код активно меняется. Сами тесты тоже пишутся по-разному, при помощи разных инструментов.