nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #821: MINIFICPP-1251 - Implement and test RetryFlowFile processor
Date Mon, 29 Jun 2020 16:47:13 GMT

szaszm commented on a change in pull request #821:
URL: https://github.com/apache/nifi-minifi-cpp/pull/821#discussion_r447110192



##########
File path: extensions/standard-processors/tests/unit/RetryFlowFileTests.cpp
##########
@@ -0,0 +1,221 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define CATCH_CONFIG_MAIN
+
+#include <memory>
+#include <string>
+#include <set>
+#include <regex>
+
+#include "TestBase.h"
+
+#include "processors/GenerateFlowFile.h"
+#include "processors/UpdateAttribute.h"
+#include "processors/RetryFlowFile.h"
+#include "processors/PutFile.h"
+#include "processors/LogAttribute.h"
+#include "utils/file/FileUtils.h"
+#include "utils/OptionalUtils.h"
+#include "utils/TestUtils.h"
+
+namespace {
+using org::apache::nifi::minifi::utils::createTempDir;
+using org::apache::nifi::minifi::utils::optional;
+
+std::vector<std::pair<std::string, std::string>> list_dir_all(const std::string&
dir, const std::shared_ptr<logging::Logger>& logger, bool recursive = true) {
+  return org::apache::nifi::minifi::utils::file::FileUtils::list_dir_all(dir, logger, recursive);
+}
+
+class RetryFlowFileTest {
+ public:
+  using Processor = org::apache::nifi::minifi::core::Processor;
+  using GenerateFlowFile = org::apache::nifi::minifi::processors::GenerateFlowFile;
+  using UpdateAttribute = org::apache::nifi::minifi::processors::UpdateAttribute;
+  using RetryFlowFile = org::apache::nifi::minifi::processors::RetryFlowFile;
+  using PutFile = org::apache::nifi::minifi::processors::PutFile;
+  using LogAttribute = org::apache::nifi::minifi::processors::LogAttribute;
+  RetryFlowFileTest() :
+    logTestController_(LogTestController::getInstance()),
+    logger_(logging::LoggerFactory<org::apache::nifi::minifi::processors::RetryFlowFile>::getLogger())
{
+    reInitialize();
+  }
+  virtual ~RetryFlowFileTest() {
+    logTestController_.reset();
+  }
+
+ protected:
+  void reInitialize() {
+    testController_.reset(new TestController());
+    plan_ = testController_->createPlan();
+    logTestController_.setDebug<TestPlan>();
+    logTestController_.setDebug<GenerateFlowFile>();
+    logTestController_.setDebug<UpdateAttribute>();
+    logTestController_.setDebug<RetryFlowFile>();
+    logTestController_.setDebug<PutFile>();
+    logTestController_.setDebug<PutFile>();
+    logTestController_.setDebug<LogAttribute>();
+    logTestController_.setDebug<core::ProcessSession>();
+    logTestController_.setDebug<core::Connectable>();
+    logTestController_.setDebug<minifi::Connection>();
+  }
+

Review comment:
       There are no rules against ASCII art that I know of. I previously expressed that I
didn't like them personally, but at the end of the discussion the conclusion was that they
provide value to the reader, therefore they are useful.
   
   I am just a contributor to the project and I happened to contribute many reviews lately,
because I believe ensuring that no easily preventable issues are committed, and the code is
of the highest quality obtainable with relative ease is usually the most efficient use of
my time. I believe it provides more value on the long term by enabling contributors (myself
and others) to work with the code more effectively.
   
   Having said that, my opinions and review suggestions are my attempt at being helpful, not
rules. I think they become de jure rules when someone proposes it and the community agrees.
On the other hand, they may easily become de facto "rules", that is, if I (or anybody) made
a suggestion that improved code in some way, then I would expect the same contributors to
try to submit an already "improved" version of similar code in their future contributions.
I usually consider de facto "rules" conventions rather than rules.
   
   I'm writing this because I don't want you or any contributors to be discouraged by my past
reviews.
   
   tl;dr: my comments are not rules




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message