Как запускать автотесты без ide

Обновлено: 07.07.2024

Я хочу иметь более глубокое понимание того, как запускаются программы C.

Но IDE мешает нам делать это.

Возможно ли, что я вручную настроил среду и напишу код в текстовых редакторах и, наконец, запустил его в командной строке?

Как говорили другие, установите MinGW (я предполагаю, что вы используете Windows) и поместите его каталог bin на свой дорожка. Откройте окно командной строки и создайте файл с помощью текстового редактора, например блокнота - назовите его foo.c:

Затем используйте компилятор gcc для его компиляции, создав исполняемый файл с именем foo.exe:

Наконец, запустите foo.exe из командной строки:

Я не понимаю, почему среда IDE должна мешать пониманию того, как работает программа на C . IDE обычно абстрагирует процесс сборки , то есть создает для вас правила сборки, запускает программу и отладчик. Это не влияет на то, как работает сама программа, она просто более «удобна для пользователя» (в зависимости от того, как вы определяете «удобный для пользователя»).

Вы всегда можете создавать программы без помощи IDE. Вы даже можете использовать Microsoft Visual Studio из командной строки, и вы вообще не увидите графический интерфейс. Аналогично XCode в Mac OS X.

Если вы хотите создать программу без использования какой-либо IDE, вы в основном пишете исходный код так же, как и с IDE. Вы даже можете использовать IDE в качестве редактора. После этого вам нужно скомпилировать вашу программу. IDE обычно имеют функции, упрощающие написание исходного кода, например автоматическое завершение элементов структуры, проверку базового синтаксиса и т.п. Если программа состоит только из одного исходного файла, это обычно довольно тривиально. Если у вас более одного исходного файла (что должно быть верно почти для всего, кроме обычного примера «Hello World»), вы все равно можете сделать это вручную. Однако это утомительный и подверженный ошибкам процесс. В мире Unix make - лучший инструмент для автоматизации этого. Вы можете использовать MinGW, чтобы получить такую среду в Windows. Другой альтернативой здесь является Cygwin. Однако вы также можете использовать nmake вне MSVC и написать ввод для него вручную (никогда не делал этого сам) - это в основном то же самое, что Makefile для make .

Создание Makefile может быть нетривиальным. Есть несколько генераторов, чтобы упростить эту задачу. Это в основном то же самое, что и IDE, абстрагируя процесс сборки. Примерами генераторов Makefile являются автоинструменты (иногда также известные как «система сборки GNU ") и cmake.

Сборка программ из командной строки также не влияет на то, имеет ли программа графический интерфейс или нет. Вы можете (снова принимая Windows) запустить любой файл .exe из командной строки. Если это приложение с графическим интерфейсом, то графический интерфейс будет отображаться, если это консольное приложение, оно будет запускаться в окне консоли.

Загрузите Cygwin и обязательно установите GCC, компилятор GNU C.

Вы можете писать свои программы на C в текстовом редакторе, компилировать их с помощью GCC, а затем запускать их.

Конечно! Для Windows доступно несколько компиляторов C, несколько из которых помогут вам:

У Visual Studio есть экспресс-версия, которая бесплатна и поставляется с компилятором. - это компилятор Gnu C, готовый к работе для Windows.
Есть много других, но вышеперечисленных должно быть . пока достаточно

Что касается текстового редактора, вы можете выбрать тот, который поставляется с подсветкой синтаксиса C, например vi , Emacs или другой текстовый редактор. Между прочим, освоение редактора действительно полезно, независимо от вашего языка.

Я не понимаю, что ты имеешь в виду. Вы хотите писать программы на C в текстовом редакторе, а затем компилировать ?? Конечно, вы МОЖЕТЕ это сделать:

Но я не уверен, что это то, что вы хотите знать.

Вы можете компилировать программы для Windows (если это то, что он имел в виду) из командной строки, используя все доступные инструменты в Windows SDK (ранее называвшемся Platform SDK, я полагаю), который можно бесплатно загрузить с сайта Microsoft. Я думаю, что в нем есть все те же инструменты, что и в Visual Studio, если не большинство из них.

Конечно. Вам понадобится что-то вроде компиляторов MinGW для компиляции вашего приложения (или вы можете использовать IDE -предоставляется компилятор). Затем просто используйте CMD и выполните соответствующие команды компиляции.

Фактически, каждая IDE предоставляет более простой способ выполнить ту же компиляцию.

Если вы хотите увидеть, как работает сборка, большинство, если не все IDE, создают журнал сборки, в котором отображаются фактические командные строки, выданные для вызова компилятора / компоновщика и т. Д. Ничто не мешает вам вводить эти команды непосредственно в командной строке.

Что IDE обычно также делает для вас, так это управление зависимостями; это сложно поддерживать вручную, и для больших проектов лучше оставить это IDE.

Вам не нужно загружать и устанавливать какой-либо конкретный компилятор или набор инструментов, как предлагали некоторые; того, что у вас есть с вашей текущей IDE, будет достаточно. Например, если у вас VC ++ 2008 (или 2008 Express), инструменты командной строки описаны здесь.

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

1 - установить TCC (компилятор Turbo C)

2- откройте Блокнот и напишите код C

3 - сохранить как a.c в C: \ TC \ BIN

4 - затем откройте CMD

5 - скомпилировать код c с помощью "tcc a.c"

6 - наконец запустить "a.exe"

Вам просто нужно установить компилятор MinGW и указать путь к исполняемому файлу gcc, и все готово. Затем вы можете написать код C в редакторе и скомпилировать его в командной строке, как в Linux.

Написание и выполнение Java-кода

Чтобы сделать пример более наглядным, я буду использовать некоторые очень простые Java-классы, которые связаны друг с другом через композиции или наследования и находятся в одном пакете с именем dustin.examples. В двух классах отсутствует функция main , в третьем классе Main.java есть функция main , которая позволяет продемонстрировать запуск класса без IDE. Ниже приведен код этих трех классов: Parent.java Child.java Main.java На следующем скриншоте показана структура каталогов с этими классами .java.Снимок экрана показывает, что исходные файлы в иерархии каталогов, представляющей имя пакета (dustin/examples, потому что информация о пакете dustin.examples) и что этот пакет отражающей иерархию каталогов находится под подкаталоге SRC. Я также создал подкаталог классов (который в настоящее время пуст) для размещения скомпилированных файлов .class потому Javac не создаст этот каталог, когда он не существует.

Здание с JAVAC и запуск с Java

Построение и запуск с Ant

Для простейших Java приложений, это довольно проста в использовании JAVAC и Java для создания и запуска приложения, соответственно, как только что продемонстрировали. Как приложения получить немного сложнее (например, код существующей в более чем один пакет / каталог или более сложных классам зависимостей от сторонних библиотек и фреймворков), такой подход может стать громоздким. Apache Ant является старейшим из "большой тройки" Явы построить инструменты и был использован в тысячи приложений и развертывания. Как я уже говорил в предыдущем посте блога, очень простой Ant построить файл легко создать, особенно если начинается с шаблона, как я изложил в этой должности. Следующий список кода предназначен для Ant файла build.xml, которую можно использовать для составления .java файлы в файлы .class а затем запустить класс dustin.examples.Main как это было сделано выше с JAVAC и Java. build.xml Я не использовал Ant свойства и не входит общих целей я обычно включают (например, "чистых" и "Javadoc"), чтобы сохранить этот пример как можно более простым и держать его близко к предыдущему примеру с помощью JAVAC и Java. Отметим также, что я включил "отладки" установлен на "истинный" для JAVAC Ant задачи, потому что это не так в случае отказа Ant, но верно с умолчанию JAVAC в. Не удивительно, Javac задача и Java задача Муравья напоминают JAVAC команда инструменты и Java. Потому что я использовал имя по умолчанию Ant ожидает файла сборки, когда он не указан явно (build.xml) и потому что я предоставил "Выполнить" цель как "по умолчанию" для этого сборки и потому, что я включен "скомпилировать" как зависимость запустить "Run" цель и потому Ant был на пути моем окружении в, все, что нужно сделать в командной строке, чтобы получить Ant для компиляции и запуска пример типа "муравей" в каталоге с файлом build.xml. Это показано в следующем снимке экрана. Хотя я продемонстрировал компиляции и выполнения простого приложения Java с Ant, я, как правило, только компилировать с Ant и бежать с Java (или скрипта, который вызывает Java, если путь к классам, являются тяжкими).

Построение и запуск с Maven

Построение и запуск с Gradle

Gradle является самым молодым, модных и стильных из трех основных инструментов Java сборки. Я иногда скептически относятся к существу то, что является модным, но я нашел много вещей, чтобы нравится Gradle (написанной в Groovy вместо XML, встроенный в Ant поддержки, встроенной поддержкой Ivy, конфигурации по соглашению, которое легко перенастроен , поддержка хранилища Maven, и т.д.). Следующий пример показывает сборки Gradle, который можно использовать, чтобы скомпилировать и запустить простое приложение, которое является основным пример кода для этого поста. Это адаптированный примере я представил в блоге Simple Gradle Java Plugin Customization. build.gradle Первые две строки из файла build.gradle указать применение плагина Java и плагином Application, в результате чего кучу функциональности автоматически этой сборке. Определение «sourceSets" и "sourceSets.main.output.classesDir" позволяет перекрывать каталогов по умолчанию Java плагина Gradle для исходного кода Java и скомпилированных двоичных классов соответственно."MainClassName" позволяет явным указанием, какой класс должен быть запущен в рамках плагина Application. Линия "defaultTasks" определяет задачи, которые будут работать, просто набрав "Gradle" в командной строке: 'compileJava' является стандартной задачей обеспечивается плагином Java и "Выполнить" является стандартной задачей обеспечивается плагином Application. Потому что я назвал сборки build.gradle и потому я указал задач по умолчанию 'compileJava "и" Выполнить "и потому что я есть установочный бен каталог Gradle на моем пути, все, что я должен был сделать, чтобы построить и запустить примеры было введите "Gradle", и это демонстрируется в следующем снимке экрана. Даже самый большой скептик должен признать, что Gradle сборки очень скользкий для этого простого примера. Она сочетает в себе лаконичность от опираясь на определенные конвенций и предположений с очень легкой механизма переопределения выберите по умолчанию в случае необходимости. Тот факт, что он находится в Groovy вместо XML также очень привлекательным! Как и в случае с Ant и Maven, я, как правило, чтобы построить только с помощью этих инструментов и, как правило, работать скомпилированные файлы .class непосредственно с Java или скрипта, который вызывает Java. Кстати, я, как правило, также архивировать эти .class в баночку для запуска, но это выходит за рамки этой статьи.

Заключение

IDE часто нет необходимости для построения простых приложений и примеры и может быть даже более накладные, чем это стоит для простейших примеров. В таком случае, это довольно легко применять JAVAC и Java непосредственно построить и запустить примеры. Как примеры принимать более активное участие, инструмент для сборки, такие как Ant, Maven, или Gradle становится более привлекательным. Тот факт, что многие среды разработки поддерживают эти утилиты сборки означает, что разработчик может перейти в IDE с помощью встроенного инструмента, созданного ранее в процессе, если было определено, что поддержка IDE был нужен как простое приложение переросла в полноценный проект.

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.

Сегодня я расскажу о том, как мы в Badoo упростили работу с Selenium-тестами, научили ребят из отдела ручного тестирования работать с ними и какой профит с этого получили. Прочитав статью, вы сможете оценить трудозатратность каждого из этапов и, возможно, захотите частично перенять наш опыт.

Введение

Со временем количество автотестов становится довольно внушительным, и приходит понимание, что система, в которой количество автоматизаторов – константа, а количество тестов непрерывно растёт, – неэффективна.

В Badoo серверная часть наравне с Desktop Web релизится два раза в день. Об этом очень подробно и интересно рассказал мой коллега Илья Кудинов в статье «Как мы уже 4 года выживаем в условиях двух релизов в день». Я советую ознакомиться с ней, чтобы дальнейшие примеры в этой статье были вам более понятны.

Вполне очевидно, что чем выше покрытие автотестов, тем бóльшее их количество окажется затронутым в процессе релиза. Где-то изменили функционал, где-то поменяли вёрстку и локаторы перестали находить нужные элементы, где-то включили A/B-тест и бизнес-логика для части юзеров стала другой и так далее.

В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза. И так по кругу. Не оставалось времени на написание новых тестов, на поддержку и развитие архитектуры и решение каких-то новых задач. Что делать в такой ситуации? Первое решение, которое приходит в голову, — нанять ещё одного автоматизатора. Однако у такого решения есть существенный минус: когда тестов снова станет в два раза больше, мы снова будем вынуждены нанимать ещё одного автоматизатора.

Во-вторых, наши автотесты для Desktop Web написаны на PHP, как и сам продукт. Следовательно, работая с кодом автотестов, тестировщик развивает в себе навык работы с этим языком программирования, и ему становится легче и проще понять дифф задачи и разобраться, что там было сделано и куда стоит в первую очередь посмотреть при тестировании.

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

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

С плюсами разобрались. Теперь давайте подумаем, какие могут быть минусы.

Тестирование задачи начнет занимать больше времени, потому что QA-инженеру придется помимо проверки функционала исправлять тесты. С одной стороны это действительно так. С другой стороны стоит понимать, что маленькие задачи у нас в Badoo превалируют над масштабными рефакторингами, где затрагивается всё или почти всё. О том, почему это так и как мы к этому пришли, хорошо рассказал глава отдела QA Илья Агеев в статье «Как workflow разработки влияет на декомпозицию задач». Следовательно, исправления должны сводиться к нескольким строчкам кода, а это не займет много времени.

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

Рефакторинг тестов

Благодаря этому мы получили тесты, которые читаются довольно просто:

И простые UI-классы, которые выглядят примерно так:

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

Обучение

На основе этих семинаров были написаны статьи в нашу внутреннюю Wiki о том, как правильно работать с тестами и с какими подводными камнями можно столкнуться в процессе. В них мы собрали best practices и ответы на часто задаваемые вопросы: как правильно составить локатор, в каком случае стоит создавать новый класс под тест, а в каком – добавлять тест в уже существующий, когда создавать новый UI-класс, как правильно называть константы для локаторов и так далее.

Сейчас, когда в компанию приходит новый QA-инженер, он получает список тех самых статей из Wiki, с которыми необходимо ознакомиться для работы с автотестами. И когда он в процессе тестирования впервые сталкивается с падающим тестом, он уже во всеоружии и знает, что делать. Само собой, в любой момент он может подойти ко мне или к другому автоматизатору и что-то уточнить или спросить, это нормально.

У нас есть договорённость, что умение QA инженера работать с автотестами, в том числе писать новые – это одно из требований для роста внутри компании. Если ты хочешь развиваться (а кто же не хочет, верно?), надо быть готовым к тому, что придётся заниматься и автоматизацией в том числе.

TeamCity

Наши Selenium-тесты лежат в том же репозитории, где и код проекта. Когда мы только начинали писать первые Selenium-тесты, у нас уже был PHPUnit и некоторое количество unit-тестов. Чтобы не плодить технологии, мы решили запускать Selenium-тесты, используя тот же PHPUnit, и положили их в соседнюю с unit-тестами папку. Пока тестами занимались только автоматизаторы, мы могли вносить правки в тесты сразу в Master, поскольку делали это уже после релиза. И, соответственно, запускали в TeamCity тесты тоже с Master.

Когда ребята начали работать с тестами в своих задачах, мы договорились, что правки будут вноситься в ту же ветку, где лежит код задачи. Во-первых, это обеспечивало одновременную доставку правок для тестов в Master с самой задачей, во-вторых, в случае отката задачи из релиза правки для неё также откатывались без дополнительных действий. В итоге мы начали запускать тесты в TeamCity с ветки релиза.

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

Но это ещё не всё.

Запуск тестов по диффу задачи

Гонять все тесты для каждой задачи крайне затратно как по времени, так и по ресурсам. Каждый тест необходимо обеспечить браузером, следовательно, нужно поддерживать мощную Selenium-ферму. Также нужен мощный сервер, на котором будет развёрнут проект и по которому параллельно будет ходить большое число автотестов. А это – дорогое удовольствие.

Мы решили, что было бы круто вычислять динамически для каждой задачи, какие именно тесты стоит запускать. Для этого мы каждому тесту присвоили набор групп, которые привязаны к проверяемым фичам или страницам: Search, Profile, Registration, Chat, и написали скрипт, который отлавливает тесты без групп и пишет соответствующие нотификации автоматизаторам.

Далее перед запуском тестов на задаче мы при помощи Git научились анализировать изменённые файлы. Они по большей части тоже называются как-то похоже на фичи, к которым имеют отношение, или лежат в соответствующих папках:

/js/search/common.js
/View/Chat/GetList.php
/tpls/profile/about_me_block.tpl

Мы придумали пару правил для файлов, которые не соответствуют названию ни одной группы. Например, у нас часть файлов называется, скажем, не chat, а messager. Мы сделали карту алиасов и, если натыкаемся на файл, который называется messager, запускаем тесты для группы Chat, а если файл лежит где-то в core-папках, то мы делаем вывод, что стоит запустить полный набор тестов.

Конечно, универсального алгоритма решения такой задачи не существует – всегда есть вероятность, что изменение в каком-то классе затронет проект в самом неожиданном месте. Но это нестрашно, поскольку на стейджинге мы запускаем полный набор тестов и обязательно заметим проблему. Более того, мы придумаем правило, как в следующий раз не пропустить подобную проблему и обнаружить её заранее.

Нестабильные и сломанные тесты

И если с тестировщиком можно договориться, то с тестами всё сложнее – они честно будут находить проблему и падать. Причём, когда баг окажется в Master, тесты начнут падать на других задачах, что совсем плохо.

В качестве багтрекера мы используем JIRA. Параллельно по cron’у гоняется скрипт, который через JIRA API проверяет статусы тикетов из этой таблицы. Если тикет переходит в статус Closed, мы удаляем запись, и тест автоматически начинает снова запускаться.

В итоге сломанные тесты исключаются из результатов прогонов. С одной стороны, это хорошо – на них больше не тратится время при прогоне, и они не «засоряют» результаты этого прогона. С другой стороны, тестировщику приходится постоянно открывать SeleniumManager и смотреть, какие тесты отключены, чтобы при необходимости проверять кейзы руками. Так что мы стараемся не злоупотреблять этой фичей, у нас редко бывает больше одного–двух отключенных тестов.

Теперь вернёмся к проблеме нестабильных тестов. Поскольку речь в статье идёт о UI-тестах, нужно понимать, что это тесты высокого уровня: интеграционные и системные. Такие тесты по определению нестабильны, это нормально. Однако хочется всё же ловить эти нестабильности и отделять от тестов, явно падающих «по делу».

Мы довольно давно пришли к выводу, что стоит логировать запуски всех тестов в специальную MySQL-таблицу. Название теста, время прогона, результат, для какой задачи или на стейджинге был запущен этот тест и так далее. Во-первых, нам это нужно для статистики; во-вторых, эта таблица используется в SeleniumManager – веб-интерфейсе для запуска и мониторинга тестов. О нём однажды я напишу отдельную статью. :)

Помимо вышеперечисленных полей, в таблицу было добавлено новое – код ошибки. Этот код формируется на основе трейса упавшего теста. Например, в задаче А тест упал на строке 74, где он вызвал строку 85, где был вызван UI-класс на строке 15. Почему бы нам не склеить и не записать эту информацию: 748515? В следующий раз, когда тест упадёт на какой-то другой задаче Б, мы получим код для текущей ошибки и простым select’ом из таблицы узнаем, были ли ранее похожие падения. Если были, то тест очевидно нестабильный, о чём можно сделать соответствующую пометку.

Само собой, тесты иногда меняются, и строки, на которых они падают, тоже могут измениться. И какое-то время старая ошибка будет считаться новой. Но, с другой стороны, это происходит не так часто, поскольку, как вы помните, логика теста отделена от логики UI и меняется редко. Так что бóльшую часть нестабильных тестов таким образом мы действительно отлавливаем и помечаем. В SeleniumManager есть интерфейс, позволяющий перезапускать нестабильные тесты для выбранной задачи с целью убедиться, что функционал работает.

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

Этот путь состоял из следующих этапов:

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

Совершенствуйте свои инструменты и делайте их проще в использовании и будет вам «щасте». Спасибо за внимание!

Я хочу иметь более глубокое понимание того, как выполняются программы C.

но IDEs останавливает нас от этого.

возможно ли, что я вручную настроил среду и написал код в текстовых редакторах и, наконец, запустил его в приглашении?

Если ответ да, то как?

как говорили другие, установите MinGW (Я предполагаю, что вы используете Windows) и поместите его каталог bin на свой путь. Откройте окно командной строки и создайте файл с текстовым редактором, например блокнот - назовите его foo.c:

затем используйте компилятор gcc для его компиляции, создавая исполняемый файл под названием foo.exe:

наконец, запустите foo.exe из командной строки:

Я не понимаю, почему IDE должна препятствовать пониманию того, как C программа строительство. IDE обычно абстрагирует здание

скачать Cygwin и обязательно установите GCC, компилятор GNU C.

вы можете написать свои программы C в текстовом редакторе, скомпилировать их с помощью GCC, а затем выполнить их.

конечно! Есть куча компиляторов C, доступных для Windows, несколько из них, чтобы вы собирались:

Visual Studio имеет экспресс-выпуск, который является бесплатным и поставляется с компилятором
MinGW является ли компилятор Gnu C готов к запуску для windows
есть много других, но те, что выше должна быть .. достаточно

Что касается текстового редактора, вы можете выбрать тот, который поставляется с C-синтаксисом подсветка, как vi, Emacs или другой текстовый редактор. Освоение редактора, кстати, действительно полезно, независимо от того, что ваш язык.

вы можете компилировать программы для Windows (если это то, что он имел в виду) из командной строки, используя все доступные инструменты в Windows SDK (ранее называвшийся Platform SDK, я считаю), который можно скачать бесплатно из Microsoft. Я думаю, что у него есть все те же инструменты, что и у Visual Studio, если не большинство из них.

конечно. Вам понадобится что-то вроде MinGW компиляторы, установленные для компиляции вашего приложения (или вы можете использовать компилятор, предоставляемый IDE). Затем просто используйте CMD и выполните соответствующие команды компиляции.

на самом деле, каждая IDE предоставляет просто более простой способ сделать ту же компиляцию.

Если вы хотите увидеть, как работает сборка, большинство, если не все IDE создают журнал сборки, который показывает фактические командные строки, выданные для вызова компилятора/компоновщика и т. д. Ничто не мешает вам выдавать эти команды непосредственно в командной строке.

то, что IDE обычно также делает для вас, - это управление зависимостями; это трудно поддерживать вручную и лучше оставить IDE для больших проектов.

вам не нужно загружать и устанавливать какой-либо конкретный компилятор или toolchain, как некоторые предложили; тот, который у вас есть с текущей IDE, будет достаточным. Например, если у вас есть VC++2008 (или 2008 Express), описываются средства командной строки здесь.

вот простой шаг, который заставит вас скомпилировать и запустить программу c без IDE

1-Установите TCC (Turbo C compiler)

2 - откройте блокнот и напишите C-код

3 - сохранить как a.c in C:\TC\BIN

4-затем откройте CMD

5-компиляция кода c с помощью " tcc a.c"

6 - наконец запустить "a.exe"

вам просто нужно установить MinGW компилятор и установить путь к исполняемому файлу gcc, и вы готовы к работе. Затем вы можете написать код C в редакторе и скомпилировать его в командной строке так же, как и в Linux.

Читайте также: